Report from FOG Solution for a Major Problem by Gale Rhoades In recent weeks, the FOG office staff has been trying to sort through a variety of submissions. Some have been uploaded to FOG #6 (or #1) and some have arrived on disk. The problems we've encountered surpass my ability to describe. We have files which have been sQueezed, crunched, ARChived or LiBRaried and we have files which apparently have gone through a combination of compression programs. We have filenames with characters which are reserved under MS-DOS and filenames with characters which are reserved under CP/M. (Reserved characters are those which the operating system will not permit you to use when naming a file.) We have CP/M files on MS-DOS formatted disks and MS-DOS files on CP/M formatted disks. And we have the most horren- dous assortment of combinations. How some of it was accomplished is totally beyond me! Enough is enough. Jack and I are spending hours trying to get at some of these files and we just do not have the time to continue doing this. Well, at least not if you want to continue to see the FOG publications, new library releases and all the other services which are provided by the FOG staff. We have therefore developed some guidelines for submitting material to the FOG libraries and publications. Exceptions will be considered but please check with us in advance. We are willing to listen to suggestions for modifications to these guidelines but only if they are presented in an organized and well-considered manner. As a secondary goal, I would hope that FOG can facilitate the standardization of filenames and com- pression programs. Additionally, these guidelines are subject to revision as the authors of industry-standard utilities develop the tools which will eliminate some of the specific problems outlined below. The Guidelines It would be very foolish to perpetuate the argument that CP/M and MS-DOS are separate and distinct. Far too many users find themselves switching between MS-DOS and CP/M machines. Some have one machine at work and the other at home. Others have both sitting side-by-side. Legal Filenames: Filenames may contain only the characters listed below: ! (exclamation mark) # (pound, number, or hash symbol) % (percent) & (ampersand) ' (apostrophe) ( (open or left parenthesis) ) (close or right parenthesis) - (hyphen, dash, or minus) @ (at symbol) 0 through 9 A through Z (upper case only!) ^ (caret or circumflex) ` (back quote) { (open or left brace or curly bracket) } (close or right brace or curly bracket) ~ (tilde) It is true that both MS-DOS and CP/M permit filenames to include char- acters other than those listed above. This list includes only those haracters which we have found to be generally acceptable to both opera- ting systems. Note that a few of these characters are partially reserved through common usage. For example, "Q" as the second letter of a file extension indicates that the file has been sQueezed. NEVER use it otherwise. "Z" as the second letter of a file extension indicates that the file has been crunched. Again, NEVER use it unless the file has indeed been crunched. The characters are listed in ascending ASCII order. The first nine often are used to place files at the head of a sorted directory because they have ASCII values less than that of a "0" or an "A". Utility Programs: These are the programs which compress files (to con- serve disk space) or which collect several files under a single filename. 1. SQueezed files (those with a "Q" as the second letter of a file ex- tension) must be compatible with Dave Rand's NewSWeeP (version 2.07 in CP/M or 1.018 in MS-DOS, both of which use Richard Greenlaw's SQ algorithm). I have yet to see a correctly named file which will not unsQueeze with NSWP. SQueezed files generally save approximately 30-35%. Text files which are of use to both CP/M and MS-DOS users should only be sQueezed. 2. LiBRaried files (those with the extension .LBR) are a collection of several related files. Often libraries include files which have been sQueezed. This combination is both acceptable and desirable as a savings of 10-50% is realized. Additionally, there are fully debugged utilities which will allow one- step viewing and extraction from .LBR files and these files are equally usable on either MS-DOS or CP/M systems. Generally these files are created on CP/M systems. 3. ARChived files (those with the extension of either .ARC or .ARK) are files which contain related files. ARC is particularly nice because it is possible, in a single step, to both condense and collect. Cur- rently ARC files are created reliably only on MS-DOS systems but the contents can be extracted with ease on either a CP/M or MS-DOS system. The established standard is to use .ARC as the extension when the file contains programs and related files specific to MS-DOS systems. Most MS-DOS shareware and public domain software is distributed (on the Remote Systems) in .ARC files. Files w ith the extension .ARK are specific to CP/M systems. ARC512 is the standard which FOG is supporting. Things to Avoid: These are the things which have caused major problems, especially lately. 1. ALL crunch programs. These programs are changing dramatically nearly every week. In most cases, files which were crunched by a later ver- sion cannot be extracted by an earlier version. Files which contain a "Z" as the second character in the extension will be discarded until (unless) the various authors can agree on some stan- dards and build RELIABLE and easy-to-use programs which allow a CP/M user to extract a file crunched on an MS-DOS system, an MS-DOS user to extract a file crunched on a CP/M system AND both CP/M and MS-DOS users to create compatible crunched files. 2. Please DO NOT mix compression algorithms except to sQueeze a file and then include it in a LiBRary file. 3. ARC files created by programs not compatible with ARC512 will be dis- carded. 4. Files which were named using illegal characters (those not listed un- der Legal Filenames above) will be discarded. 5. Never sQueeze or crunch a .LBR or .ARC file! 6. Never sQueeze or crunch a file which will later be included in an ARC file. 7. NEVER rename a file before submitting it to this office! You may re- name any file or program for your own use but please do not distribute it to others except under the filename assigned by the author. This is particularly important with public domain software. 8. Please do not sQueeze, LiBRary, or ARChive a file and then rename the file. If you want to rename a file you created, please do so before using your favorite utility. Renamed files cause serious problems when we are extracting several files on the same disk. Submissions It is amazing how many submissions (both for the libraries and the publications) arrive with nothing to identify the sender, the disk format, the intent of the sender, etc. Each disk submitted should have a label to tell us: 1. The name and address (and membership number) of the sender. 2. The format of the disk. 3. If text files are included, what word processor was used. If it is possible, we would prefer that the files be submitted in WordStar or standard ASCII format. 4. If it is not a submission, please include a cover letter so we know WHY it was sent. 5. If it is a submission, what would you like back? Volunteers do most of the copying to overwrite the disks before they are returned to the senders. Normally the volunteers are not able to look up your address and we do not have records of the library disks you already have or the disk formats you can read. 6. If possible, include a file with the CRC values so that we can check for damage to the files if we encounter problems. 7. Keep the filename unique. Please do not use FOGHORN, FOGLIGHT, FOG, LETTER, or similar filenames. Files uploaded to FOG #6 or #1 should: 1. Include sender's name, address, and membership number. If you are uploading a textfile, place this information at the beginning of the file. If you are uploading a library submission, include this infor- mation in a "README" file. 2. If more than a single file is being uploaded, please collect all re- lated files in either a LiBRary or ARChive file. Be sure the "README" file is included. SQueeze text files before adding them to a LiBRary file; do NOT sQueeze them before using ARChive. 3. If possible, include a file with the CRC values of each member. 4. Keep the filename unique. Please do not use FOGHORN, FOGLIGHT, FOG, LETTER, or similar filenames. Submissions for the FOG Publications Lately, we have been receiving a large number of lengthy letters and articles by mail. This is great except for one small problem - these letters are not in computer-readable form. Therefore, we wonder if authors realized that, in order to publish the submission, we have to first retype these otherwise excellent submis- sions? We have reluctantly begun returning such letters with the request that they be returned on disk. Remember folks, we will return your disk overwritten with a disk from the library -- just tell us which disk you'd like to have. Effective immediately, we will be unable to rekey a submission which is longer than two paragraphs. If you have artwork which accompanies the submission, please continue sending that as hardcopy. Just insert it into the disk mailer. Please include your name and address at the start of each article. It is much faster to delete a couple extra lines than to search for the information. Please omit (or delete) ALL print control codes, regardless of what you think we can read or use. We are experimenting with a variety of "desk- top publishing" software packages and print control codes can make a file nearly useless. If you want to assist us, include a hardcopy of the formatted file. Please avoid indents, tabs, and other offsets. Keep all the margin flush left and use blank lines for separation. Start and end non-printing comments with a tilde ( ~ ). Submissions are always needed for the FOG publications and, of course, greatly appreciated. To all the authors and others responsible for such submissions, our sincerest thanks for your efforts and support. - Gale Rhoades