LIBRARY.CTL   Microcomputer Diskette Library Control.

04/25/81.     T. McCormick.


	Control  of computer libraries is well developed in large 
computer  operations.  Only  tiny operations can get  by  without 
specific  rules for naming programs and data  files,  segregating 
test files from production, indicating as-of dates, etc.

	With the rapid growth of microcomputer use,  and with the 
continual improvement in disk storage capacity per  dollar,  many 
business  and  hobby users are discovering that with  no  library 
plan,  too  much time and effort are wasted looking for the right 
version, starting to run the wrong version...again, etc.

	It  is  possible  to acquire and  store  more  files  and 
programs than you can manage without some library system.

	Micro operating systems,  editors, and utilities offer an 
occasional  assist  in one way or another such as  creating  .BAK 
backup  file copies automatically.   But the user is left to  put 
his  library control scheme together by himself.  He often  lacks 
the  experience  which comes from years of grappling  with  these 
problems,  and  is  forced to discover solutions one at  a  time.  
This results in a weak start, and continual change.

	I have made many mistakes related to computer  libraries, 
and  have  seen many others.   As computer center manager  for  a 
nationwide accounting firm, we daily were working with files from 
all kinds of outside program libraries.   I would like to pass on 
a  few suggestions based on my experience with about 300 computer 
libraries over an eleven year period.

	The following is not intended as a exact prescription for 
you,  you will have to decide what fits,  and what doesn't.  I'll 
use  my library control methods as an example,  knowing that  you 
will have to adapt it to your circumstances.

	Here is a summary of important rules:

	1.  Never alter a "distribution" diskette in any  way.  A 
distribution  diskette is one you receive from someone else,  and 
for which you usually have paid money.   You may have to send  it 
back  to get a new release at the "update" price rather than  buy 
another  license!   You may not be able to read it next year  and 
you  want a fresh copy at nominal charge.  You may want to get  a 
bug fixed at no charge.  Do NOT change anything on this diskette. 
N O T H I N G . 

	2.  A program that is one bit, one byte, or one statement 
different  from another MUST have a different name.   There is no 
such thing as	"same as....,  except".  Resist the temptation to 
leave the names the same when they are "only slightly" different.  
Subtle differences are hard to sort out six months later!  Subtle 
differences may be much harder to find than large differences  or 
gross errors.

	3. Follow your system rigidly.

	4. Label things immediately, while they are fresh in your 
mind.  Little peel-off dots and labels are inexpensive,  and easy 
to use.  Office supply stores have a rainbow assortment (Avery is 
one  of the brand names) and they are cheap.   Color  coding  can 
segregate  test from permanent files,  release 2 from release  3, 
etc. without any writing.

	5.   Begin  library  control  at  once:  it  gets  harder 
geometrically as you acquire more stuff.

	6.  When you initialize/format a diskette,  place a small 
peel-off  label  (I  use  one-inch  dots  on  it  indicating  the 
operating system version you used, date, and density or format if 
you have more than one. Eventually, you will have more than one.

	7.  Specifically  label backup copies,  and write-protect 
them.  Store them separately from daily-use diskettes. Store them 
inside,  where the humidity and temperature are fairly  constant. 
Exchange  backup storage with another user,  if you can.  Do  not 
store diskettes or cassettes in your car trunk!

	Why bother with backup?   Have you ever entered 

	A>ERA *.*     instead of    A>ERA B:*.*    or

	A>PIP A:=B:*.*[V]  instead of
	      B:=A:*.*[V]

	HUMMMM?

	You say you're not that stupid??   OK.


	8.   Establish  categories,   and  label  your  diskettes 
accordingly.	For example, Proprietary software such as MBASIC, 
CP/M, etc could be replaced by a dealer.  Your modifications, and 
custom programs could not.  They should be protected to a greater 
degree.

	9. Never keep all your backup in one place. Two suitcases 
ten  miles  apart  is  more secure  than  one  bomb-proof  vault.  
Remember, with all the electrical equipment in one computer room, 
a  small  fire could destroy alot of diskettes in a  hurry.   Bet 
you've got 'em stored close by so they'll be nice and handy too!

       10.  Data-file diskettes change periodically.  Use a peel-
off label to indicate clearly the filenames,  and as-of date.  Do 
not  store  backup  of  data files on  the  same  diskette  under 
different filenames.  Diskettes can become unusable no matter how 
careful you are.

       11. I recognize three flavors of diskettes:
		a. never used.
		b. initialized/formatted, not used.
		c. in use, contains one or more files.

Come  up with a scheme to indicate each of these.  I do not put a 
peel-off file label on never-used diskettes.  If I see a diskette 
with  no  peel-off  label  at  all,   I  know  it  has  not  been 
initialized/formatted.   When I initialize/format a  diskette,  I 
place  a  one-inch  colored dot on it  indicating  the  operating 
system  version,  today's date,  and the recording format/density 
with  which it was initialized/formatted.  Such diskettes have  a 
directory,  but  do not have any files.  Every diskette  of  mine 
which  contains a file has a large peel-off label indicating  the 
name(s),  or something else indicative such as "SYSTEM",  "WORK", 
"MBASIC", etc.

	Never  write  on a distribution copy,...the diskette  you 
received from someone else.  If you alter such a diskette in  any 
way, you usually void any warranty. Do not add to it, delete from 
it,  or rename anything.  Do not even write a .DOC file, a volume 
serial  number,  or  anything else on it.   You should  label  it 
"DISTRIB", and make a complete fresh copy from which to work.  If 
you have to send it back for an update to the next release, or to 
get a bug fixed,  or because you can't read it anymore,  etc. you 
can not expect the people you got it from to listen to your story 
of how "..it's exactly like when you sent it to me,  except....". 
It  is  bound  to  cost you money sooner or later  if  you  alter 
distribution diskettes.

Since you will not be altering them,  you must count on  peel-off 
labels to identify your distribution diskette contents, etc. 

		A. Apply a peel-off label saying
		   "DISTRIB".

		B. Write the date received on that
		   label.

		C. Write protect the diskette.

		D. Make your working copy from which
		   you will begin tailoring.
		   Clearly label this copy.
		   I call mine "DISTCOPY".

		E. Make a 2nd copy of valuable stuff
		   for an off-site location. This
		   might be your office, or another
		   user. It should NOT be your car
		   trunk, or other outside storage.
		   Humidity will ruin your diskettes.

		F. Store the "DISTRIB" diskette with
		   other "DISTRIB" diskettes, not with
		   the working copies of that system.
		   Physically separate backup copies
		   from those you use daily.


	Now that we have secured your distribution diskette,  and 
made  a working copy,  we are ready to tackle one of the cruelest 
problems in using a computer.  Give some thought to the NAMES you 
apply to programs in the process of being changed.

	One  scheme is to add a "suffix" to the filename,  or  to 
change the filetype to .001  .002  etc.

	You  want to keep some consistency so that the names  are 
meaningful,  and wildcards can be used with utilities   (example:  
PIP  B:=C:PROGM???.BAS[V]).   But  you  must  name  your  changes 
differently  from the distribution filename,  and from your other 
changes. How will you know which is your latest version? How will 
you know which is your latest version which works?

	It  is a mistake to count on keeping the  same  filename, 
and using different diskettes.  The trend is rapidly toward large 
capacity,  non-removeable hard disks.   In a few years,  everyone 
will  have  5 or 10 MB disks!  Anyway,  it is easier to  learn  a 
disciplined approach,  and follow it,  than to spend alot of time 
making  gobs  of  filecopies and then trying to  remember  what's 
what.

	If  you begin changing a program called  BUDGET.BAS,  you 
might  call your first  modification  BUDGET01.BAS,  BUDGET1.BAS, 
BUDGET.001, BUD1.BAS, B1.BAS etc. It is a matter of taste, and of 
how large your library is.   The larger it is,  the more specific 
you have to be...you might have more than one budget program.  If 
you  have an editor,  and you save the basic program as an  ASCII 
file  (ie.  SAVE "B:BUDGET01.ASC",A),  you may want to adopt  the 
.ASC  filetype naming convention to clearly identify it as  ready 
for your editor, or to be modemed to another user.  Be aware that 
some operating systems have a limit of six character names.

	As  you  modify  programs,  add remarks in the  front  to 
indicate  the as-of date,  version,  etc.  Professional  programs 
display this information as they are read in to be executed:  for 
example,  note  how MBASIC clearly identifies it's  version/date.  
In  that  way,  the  user knows from looking at the  CRT  if  the 
correct version of the program has been loaded. Many programs are 
dependant  on  the  release/version  of  the  operating   system. 
Unfortunately,  the  program names often do not change,  but  the 
programs  are  different.  Some will not run with  new  releases. 
Peel-off  labels  will help with this  problem  also:  ie.   "1.4 
depen", etc.

	After  you have migrated to a new release/version of your 
operating system,  a new set of problems appear.  Programs  which 
used to work,  now do not. You may have to rename some of them if 
you  are  going  to  retain old  versions  (everyone  does).  For 
example, you may want to rename CLIST to CLIST15 or CLIST16 if it 
runs  on ver 1.5 or 1.6.  Then you can use CLIST for  the  latest 
version.  This  approach  requires  you to rename a  lot  of  OLD 
programs  that do not run on new releases.   I prefer this to the 
next  method because I do not mix much among different  versions. 
If I did, I would do as below.

	Another approach (please do not mix this with the  above) 
is  to  identify  the release in the name  (CL15  or  CL16),  and 
perhaps shorten the names at the same time.   But this starts you 
talking a "different language" than the documentation,  and other 
users.  You  have to translate their conversations to your naming 
scheme.  If  you  are bright and independent,  or  shorten  names 
anyway,  then this has the advantage of avoiding a lot of  donkey 
work  at  conversion time.....you rename on your working copy  of 
the DISTRIB diskette,  and then PIP them as you go along.  You do 
not have to go back and rename a dozen copies of every program.

	There  is no right or wrong way;  it is a matter of  your 
style.   Remember though,  you can't avoid the work.  It's just a 
matter of when and how you prefer to do it.   I prefer NOT to mix 
different  releases if I have a choice.   I would rather generate 
entire new diskettes for the new release.   In this way,  I  have 
complete diskettes to go back to if I want (or need) to.  No half 
this,  and  half  that.   I avoid having to flip something  on  a 
diskette  to tell it which flavor I want to run.  If you get very 
many of these "switches" on a diskette, it is a long process just 
to  find out where your beginning from!   I make specific  copies 
and  label  them  as  to options in  effect  on  that  particular 
diskette.  Saves me time and nerves.

	I hope one or two of these ideas are helpful.  Good luck.

	*********************************************************