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. *********************************************************