THIS DISC HAS A SYSTEM DEMO SET UP WHICH WILL BE ALTERED WHEN IT IS RUN. TO KEEP THIS COPY OF THE DEMO INTACT FOR ANYONE ELSE TO TRY OUT, EITHER (1) INITIALIZE OR RE.LABEL A NEW DISC "SYSTEM", AND COPY AFS71, ASFR, AFST, MMINDEX, CKSUMLEX, AFINDEX, (IN ANY ORDER) AND THE FIVE TEXT FILES AFSTEST1 THRU AFSTEST5 ONTO IT, THEN USE THAT FOR TRIALS OR (2) MAKE A COPY OF THIS WHOLE DISC. A FILE (DISCOPY) THAT DOES THIS IS ENCLOSED. COPY AFS71, CUSTUTIL/KEYWAIT AND DISCOPY INTO RAM, AND WITH (AT LEAST) TWO 9114 DRIVES ONLINE, CALL DISCOPY, FOLLOW PROMPTS. ANY DISC ANY DRIVE. To try out the enclosed version of Autofile ensure that STRINGLX, KEYWAIT or CUSTUTIL, CKSUMLEX (enclosed), and any HP text editor is in the 71. As well as EDLEX, an HP BASIC text editor is also required IN THIS VERSION, but it could easily be replaced by any other text editor or (even preferably) a small custom built text entry routine. The presence of one 9114 on an HP-IL is assumed if you are reading this. Up to 15, (or is it 16?) primary-addresed 9114s or 82161As may be online in any order. When you get a prompt to load a medium (by label volume) whether it is on tape or disc, and which drive is used, is immaterial. The routines work OK in the LCD, but are flasher on TV. COPY AFS71, AFST, and AFSTEST1 thru AFSTEST5 into RAM, and leave this disc in the drive. In this version the system expects to find AFSR and MMINDEX only on media, and will abort if either is in RAM when an update is requested, so if you have COPYed these files into the 71 to make a trial disc as in paragraph 1, or to look at them, whatever, then be sure to PURGE them before continuing. The abort is quite arbitrary and is easily removed. I haven't done so because, although it was originally there to help in my perenniel confusion over which version of a program under development is actually running at any time, there are valid(ish) reasons for leaving the restrictions there in everyday use mode also. AFS stands for AutoFile System, and the 71 denotes that it is the 71-based system file. Apart from that name, COPYed at installation, the user has to remember only three names in the operation of the system: AFSL (AFS Log) AFST (AFS Track) and AFSU (AFS Update). With two key assignments this reduces to only one (AFST). AFSTEST1 thru AFSTEST5 are a small collection of archeological inscriptions found on an ancient rune, used here to provide an alternative source of interest in the demonstration, for those who are bored already. These files are already being tracked with the checksumming function written by John Baker. To see this in action, do the following: CALL AFSU. If all is well it should end "Updating 0 files". Make a change (one character will do) in one or more of the AFSTEST# files. Use the text editor shell in AFS71 file, to try it out too. (This shell helps in manually logging files, as described later). Either assign to a key and press it, or key in CALL TEXTED("","") to enter the text editor shell. At the prompt Edit =(?)- ADDR type in either )AFSTEST# or (AFSTEST#, where # is a # 1 thru 5. The parentheses select between Nigel Davies' multiline fullscreen TV or LCD editor (on BBS last year) and the HP single line editor, with the HP editor being used as default if Nigel's isn't present. If no parentheses preceed the filename a simple filesearch routine is run on the specified file: "Q" to quit, any other key to continue, "Done" displayed after last match. (ADDR is my personal "default editing file" - change it at line 610 of AFS71, if desired). CALL AFSU again. This time it should identify the files which have been changed and stop, after "Collating" them against the volume label of the medium/a the files are to be updated onto (in this case SYSTEM, this demonstration disc), with an offer that you edit the collation. For the moment decline by pressing "N" (or similiar, but not "Y"). The altered files will be updated on disc. That's it. Whenever a file (of any type), which is being tracked by the system, is altered it will be updated onto the appropriate (pre-specified) media at the next execution of AFSU. To get a file tracked in this way, put its name in the AFST file, on a separate line, e.g. FILENAME That's it. After the file is first "tracked" its checksum and time of checksumming will appear after it: FILENAME=ccccccc@YDDDHHh The time of checksumming is not further used in this version. It is required by a separate facility which enables a each user in a group sharing a common set of files (i.e. using the same discs) to all get automatic updates of any files which any one of them has individually updated (e.g. programmers in joint program development, a dispersed sales team maintaining a single central stock register, and so on). After each run of AFSU the # following the "=" will be the current value of the file's checksum. To untrack a file, just remove its entry from AFST. Any entry in AFST that doesn't have a corresponding file in 71 memory is ignored by AFSU. If you track a BASIC file in this way be sure to compile it after making any changes (RENUMBER 1,1,1,1) so that it doesn't get repeatedly updated thereafter as running it does the compiling path by path. With a new file to "track" specified in AFST (make it a file NOT on this disc, so the 'how to enter a new file' bit can be demonstrated) CALL AFSU again, and this time respond to the invitation to Edit the collated FILE.MEDIA file with "Y". The contents of the file specify ("program") the recording sequence that follows. In this version the HP BASIC text editor is used, but a small purpose-built input routine could be more user-protective. Each line of the file must contain one, and only one, filename. If the filename is not followed by a .VOLUME label the entry is ignored by the update routine, but the filename remains logged for a future update. (A .VOLUME label not preceeded by a file name is ignored and discarded). If the filename is followed by a .VOLUME label then the file will be recorded to that medium, and the filename removed from the log, unless there is a also a "-" character on the line, in which case that file will be PURGEd from that medium. In this version only one other control character is recognised: "*" appearing on a FILENAME.VOLUME line causes that medium to be added to or updated in the system index. The control characters may appear on either or both ends of a line, in any order. Thus if, after editing, the collated file reads ALPHA BRAVO CHARLIE.ONE -DELTA.TWO* ECHO FOXTROT.THREE*- *GOLF.FOUR -.FIVE* DELTA.SIX* GOLF.ONE CHARLIE.FOUR the update will record files CHARLIE and GOLF to media ONE and FOUR; record file DELTA to medium SIX and purge it from medium TWO; record file FOXTROT to medium THREE; and ignore files ALPHA, BRAVO, and ECHO, but leave the names logged for a future update. Media TWO, THREE, FOUR, and SIX will be added to or updated in the system index, and medium FIVE will be ignored and forgotten. The line order in the collated file is immaterial. The above example is bit more complex than the average update, in which the editing processs consists of refusiNg the offer to. On exit from the editor the update will proceed automatically to operate as specified, with the user required only to load discs into the drive(s) as prompted. ********************************************************** Note that when this system prompts the user to load a medium then it means just that: if the medium is already in situ then partially eject and REload it. At all/any prompts for media loading WAIT until all drives stop whirring and clanking about. I haven't yet found a really good way to synchronise the appearance of loading prompts with drive readiness (9114As quite happily SPOLL not busy seconds before they settle down mechanically). *********************************************************** If any key is pressed when a medium has been prompted for the program will abort. Any files still unrecorded at that point will remain logged for future updating. The update routine concludes by reporting either "Update Done", or - if not all files have been recorded - "Partial Update Done". In the latter case, one or more files remain logged for update. The text file log of files to update, AFSL, is simply a list of filenames, one to a line. It may be altered at will, using a text editor, or left for automatic management by subprogram AFSL (which housekeeps textfile AFSL). At the next update ASFL is first augmented by the AFST scanning routine, then expanded by the collation routine, which associates the filenames with the media they are to be recorded onto. During the actual update those files successfully dealt with are deleted. At the end of the update the file is collapsed to contain only the names of those files not dealt with OK. Not all files are conveniently autotracked. Manual logging, directly editing the AFSL text file, is possible, or two included semi-automatic logging facilities, separate from AFST, can be used. (1) The text editor shell quits editing files that are named in AFST directly, but on quitting files that are not named in AFST the user is asked if a media update of that file is required. Pressing "Y" logs the filename in AFSL. (2) Make the key assignment in DEAFQUAY by choosing and typing in a free keyname, or using the ")" as written. Thereafter, in user mode, when the assigned key is pressed the prompt "(Save)" appears, after which pressing "(" will call AFSU while pressing ")" will add the name of the current BASIC file to AFSL. There is no facility in the current version for removing .VOLUMEs from the system index. This index is kept in the textfile "AFINDEX" on the .SYSTEM disc, and each .VOLUME entry consists of one or more lines of filenames (separated by colons) followed by the .VOLUME label. To remove a .VOLUME simply delete all lines relating to the file, from the .VOLUME label being deleted, up to but not including the preceeding .VOLUME label. AFINDEX may be in RAM when AFSU is called, but it is preferable to COPY it back to .SYSTEM and PURGE it from memory to ensure system integrity.