LBSOS KRNLI/O ERRORFILE 'SOS.KERNEL' NOT FOUNDINVALID KERNEL FILExةw,@  4  J  ȱ⩤i8#) ) 8Le T H E R E T R I E V E R File Recovery Utility for the Apple /// USER GUIDE D A DataSystems - 1984 PlaIII.DAD.031123Bu' *MENU.MAKER }>DISKNAME.DAT!)PRINT.ALL +USER.MANUALbc%SEG.T jŸ/ m#im#iЛ#Lȱ  6L憦  Lsmm l y` @8(Je稽 ʈced into the Public Domain - 1988 (Manual Edited to Reflect PD Status) The The Retriever software supplied to you is Copyrighted 1984 by D A Datasystems. Although every effort has been made to ascertain co  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~ THE RETRIEVER is an Apple Business Basic program. As a WAP /// SIG PD disk, THE RETRIEVER runs under the Menu.Maker program selector. Simply highlight the "Run.Retriever" selection, press Return, and the program will run. vering partial files under many circumstances. THE RETRIEVER cannot assist in recovering a file which exists on a damaged diskette or hard disk. * * * HOW TO USE THE RETRIEVER anently lost. THE RETRIEVER may not be able to recover all or part of a file if it is not used immediately after the file is deleted. Since this cannot always be the case, THE RETRIEVER has facilities to assist you in reco If you delete a file and then alter or save other files on that disk, it is possible that parts of the disk which previously contained data from your deleted file will be over-written by the new data, and thus permcover inadvertently deleted files on your Apple /// floppy diskettes or hard drives. In most cases the lost data is fully and reliably restored. * * * WHAT THE RETRIEVER WILL NOT DO Appendix E - Special User Notes .... 30 The Retriever D A DataSystems WHAT THE RETRIEVER WILL DO THE RETRIEVER will reRetrievals .... 12 Bitmap Faults .... 16 Appendix C - Messages and Error reports .... 21 Appendix D - Glossary of terms & References .... 27 Appendix A - How THE RETRIEVER works page 6 Appendix B - Anomalous situations .... 11 Overview .... 11 Multiple Possible irst time What to have on hand before running .... 2 the program What you see on the screen when the .... 3 program runs APPENDICES e 1 What the program will not do .... 1 How to use the program .... 1 What to do before using the program .... 2 for the f TABLE OF CONTENTS TABLE OF CONTENTS page 0 THE RETRIEVER What the program will do pagtems 3792 Windover Dr Hamburg, NY 14619 716-648-2462 The Retriever D A DataSystems rrect performance of The Retriever, we cannot guarantee that it is bug free. WE WILL MAKE EVERY REASONABLE EFFORT to assist you with any problems or questions that may arise. D A DataSys Follow the brief instructions that appear on the screen. When finished, THE RETRIEVER will return you to Menu.Maker. Thats all there is to it !! * * * -1- The Retriever D A DataSystems WHAT YOU SHOULD DO BEFORE USING THE RETRIEVER FOR THE FIRST TIME A. Review this manual. Although you've alrea A request that you WAIT FOR "INITIALLIZATION"... PLEASE DO SO, it only takes about 15 seconds. -3- The Retriever TIMATING HOW MUCH YOU WOULD HAVE SPENT RE-ENTERING THAT FILE MANUALLY, OR SOMETHING SIMILARLY REWARDING. 1. A perhaps somewhat garish sign-on series containing... A copyright notice which you'd expect. INSERTION AND FILE NAME THE PROGRAM RUNS ON 'AUTOMATIC PILOT'. UNLESS SOMETHING UNUSUAL COMES UP - A SITUATION WHICH IS ALWAYS IDENTIFIED BY A WARNING BEEP - FEEL FREE TO SPEND THE TIME ES A FILE RETRIEVAL SESSION IS SIMPLY DESCRIPTIVE STATUS INFORMATION INTENDED TO REASSURE YOU THAT EVERYTHING IS PROCEEDING APACE...AFTER YOU HAVE ANSWERED THE TWO INITIAL REQUESTS FOR DISKETTE * a sign-on sequence * a divided or 'windowed' screen * a series of requests for information & messages NOTE THAT ALMOST EVERYTHING THAT IS DISPLAYED ON THE SCREEN DURING eleted file was previously found. -2- The Retriever D A DataSystems WHAT YOU SEE ON THE SCREEN WHEN YOU RUN THE RETRIEVER E RETRIEVER diskette using your System Utilities Disk - System Configuration Program (SCP). WHAT TO HAVE ON-HAND BEFORE RUNNING THE RETRIEVER The Floppy Diskette or Profile or other Drive unit on which the accidentally drs for the standard built-in and external Apple /// floppy drives and the Profile hard-disk drive. If you will be working with any other drives you should add the appropriate device driver to the SOS.DRIVERS file on THany other Apple /// application, THE RETRIEVER must be able to obtain access to the particular disk or drive specified through an internal piece of software called a Device Driver. THE RETRIEVER comes supplied with device drivethe additional worry of 'learning' this program under the high-stress circumstances that might lead to its being used on a real data file. * * * PLEASE NOTE As with BASIC or SYSTEM UTILITIES or your application (e.g. Visicalc) and delete a file or program on that disk. Now run THE RETRIEVER and get a feel for how simple it is to use. You don't want to have re-run THE RETRIEVER; but, as we've said before, familiarity, in these cases, breeds content-ment. B. Testing on dummy files. Go ahead. Make a backup of a backup disk then go in to note the discussions of the two 'ANOMALOUS SITUATIONS' that may arise during file retrieval. If either these situations does come up you can always exit THE RETRIEVER, review the manual, then dy seen the entirety of the operating instructions above, you owe it to yourself to be familiar with what will be happening when THE RETRIEVER goes out and does its best for you. IN PARTICULAR, D A DataSystems 2. A 'WINDOWED SCREEN' containing six significant segments. _____________________________________ | a | |____________________________________| | b | |____________________________________| | | | | ibed in later sections of this manual. * * * -5- The Retriever D A DataSystems lowed by a prompt to run the program again if you like...thats it. ANY OTHER MESSAGE which occurs represents either an error or an anomalous situation which must be responded to. These messages and responses to them are descr to quit. This allows another opportunity for "cold feet exit". * * * PROCEEDING, you will observe a further sequence of status messages then, finally a "successful retrieval" message folessages describing the retrieval process. If a match is found for the file you are retrieving the message : MATCH FOUND will be displayed and you are requested to press any key to continue or "Q" to retrieve. Be sure to start with the device name and to include all subdirectory levels as prompted by the message. * * * AFTER THIS you will observe a variety of informational status mline. When this is complete you are prompted to type in "GO" . Any other response will QUIT the program now. SECOND, a message will appear requesting that you type in the 'full pathname' of the file you wish T, you will be asked to either insert the floppy diskette containing the soon-to-be-retrieved file in an appropriate drive, or to verify that the appropriate fixed volume device (e.g. Profile or other hard disk) is on iever D A DataSystems 3. Messages and Requests for Information After you have gotten through the INITIALLIZATION process, two messages will come up in the main MESSAGE WINDOW. FIRS which counts down during lengthy functions to remind you that the program is, in fact, doing something. -4- The Retrhted this is F.Y.I. only. e. ATTENTION POINTER WINDOW - pointing you to (f). f. ATTENTION MESSAGE WINDOW containing, at various times, Warnings, error messages, and the TIMER at first. c. MAIN MESSAGE WINDOW d. CURRENT FUNCTION Informational WINDOW in which the specific activities of the program are highlig |_____|______________________________| a. PROGRAM TITLE and heading WINDOW. b. FILE NAME reminder WINDOW which will contain the name of the file being retrieved...blank | | | | | | |_____________________|______________| | e | f | | | | | | | c | d | | | | | | | Appendix A HOW THE RETRIEVER WORKS BACKGROUND DISTINGUISHING DISKS Floppy Diskettes and Hard Disks such as the Profile are sometimes referred to as "NON-VOLATILE" data storage formats. This distinguishes them from the "VOLATILE" memory storage inside your APPLE III. The latter is extremely fast but the information stored there is irretrievably lost once the computer is turned off. The formes of the game there are segments of the disk which are reserved for keeping track of what, exactly, is on the disk, and where it is. These segments are the DIRECTORIES and SUBDIRECTORIES and the DISK MAP. TRIEVER identifies these altered items and resets them to identify the file as back in existence. These are described below. THE INSIDE TRACK For each disk or diskette which is formatted according to the APPLE III ruls advantage of the fact that SOS does not physically erase the data associated with a file when it deletes that file, it simply alters four 'housekeeping' items which are normally associated with existing files. THE REcation program running either as an interpreter on its own (e.g. AppleWriter III or Systems Utilities) or under the control of a language system (e.g. an Accounting System written in PASCAL). TAKING ADVANTAGE THE RETRIEVER takehe Apple III Sophisticated Operating System (SOS) but this function must be requested by a higher level program such as a language system/interpreter (e.g. PASCAL "Remove" or BASIC "Delete" commands) or an appli that occurs when it becomes so easy to produce and manipulate - an explosion that is occassionally best managed by 'culling' a file or two or three. APPLE SAUCE FILE DELETION on the Apple III is a function of tEABLE. Changing times and budgets are reflected in changing information and changing files. (Also, for the APPLE III, changing diskettes, as we all know by now, sigh !). Less fortunate is the inevitable explosion of information -6- The Retriever D A DataSystems CHANGING TIMES Happily for all of us using the beasts, this FILE INFORMATION, although non-volatile is NOT UN-CHANG we do note that if you delete SOS.KERNEL you can go and copy another copy of it on another disk...it has not changed - not so with last month's payroll). * * * end simply separate, more general, pieces of information that you need to use your APPLE III; as such, they too are stored on disk as FILES and are considered in the following as just another manifestation of this form. (However,ms and Operating Systems manage information associated with other programs or Computer resources such as the keyboard or disk drive. However, these PROGRAMS, LANGUAGES, DEVICE DRIVERS AND OPERATING SYSTEMS are in the es of them to be written in Human-readable forms (so they say) called programs...collections of which make up your CALC or ACCOUNTS RECEIVABLE "Application Package". More intricate sequences of instructions called language syste groupings on a disk called FILES (e.g. ACCOUNTS.JUN or MASTER.MAIL.LST). Programming languages such as BASIC or PASCAL allow the large number of intricate sequences of instructions required to manipulate these FILES and piecer are somewhat slower but the information stored on these media remains available even when the APPLE III is off. FILE THIS INFORMATION, which you the computer user are primarily interested in, is usually stored in named -7- The Retriever D A DataSystems THE PECKING ORDER DIRECTORIES & SUBDIRECTORIES are similar to tables of contents which identify groupings of files by name and contain information about their size and location on disk. The form of this size and location information depends on the type of file; one common form is to have the directory contain the disk 'addre, etc., over the old entry. The next time SOS needs to expand a file on the volume it simply takes the first block whose bit in the bitmap is set... and writes the new data to that block, OVER WHATEVER WAS THERE PREVIOUSLY. but... WARNING... The next time SOS is asked to create a file on that volume it simply scans down it until it finds an entry 'slot' which has a type-byte of zero and uses it for the new file, writing the new name, datefied date of the file is updated to the current date. THATS RIGHT THATS RIGHT... SOS does not erase the name from the entry and it does nothing to your PAYROLL data sitting out there on blocks 17,154 and 279... 3. Change all the BITMAP bits associated with disk blocks used by the file, 'toggling' them, from 0 ( = block used) to 1 ( = block free). 4. In a sort of a last gasp at audit trailing the Last Modies a file it does four things, to whit : 1. Subtract one from the file-count byte for the appropriate directory. 2. Set the type-byte of the file to 0 (zero), setting, as we say, the DELETE FLAG. record keeping if you think about it. -8- The Retriever D A DataSystems FOREGROUND TO WIT When APPLE III SOS delet given block's status. Thus the Disk Map is sometimes referred to as the BIT MAP. A single APPLE III 140K floppy contains 140K/512 = 280 blocks and thus the BIT MAP will be 280 bits or 280/8 rounded = 35 bytes, quite efficient blocks, each of which contains 512 bytes or characters of information. Since we only need to know whether a particular block is available or not we can use a single, infamous, BIT with value 1 or 0 to 'flag' a ch the same way that a table-of-contents in a book breaks down the segments of the book by pages, not words, the disk map keeps track of blocklike 'chunks' of disk and the SOS will only allocate disk space to files in units of P is a collection of information on any disk (or volume as it is generically and properly called) which identifies which storage areas on the volume are "free" - that is available for use by new or expanding files. In mu directory... the FILE-COUNT byte. Each file entry in a directory has one byte which describes the 'storage type' of the file and the length of the file's name... the TYPE-BYTE. CHUNKY APPLE SAUCE A DISK MAy struggles to attain - and a very handy one if you've got 5 meg of hard disk and 400 files to keep track of). TWO BYTES Each directory reserves one byte to keep track of the count of the current number of files included in thatow directories themselves to be file entries within a larger or higher level directory, thus accommodating 'trees' or hierarchies of related information (a facility which a very popular Infinitely Benign Machine only recentlss' of a piece of information associated with the file called a KEY BLOCK which itself contains the specific disk 'addresses' of all the scattered parts of the file. Part of the POWER of the APPLE III SOS is its ability to all -9- The Retriever D A DataSystems OBVIOUS AT THIS POINT THE RETRIEVER goes out to the directory specifically looking for TYPE-BYTES set to zero and matches your requested file name against the name parts of those 'phantom' entries. If it finds a match it RETRIEVES the file by adding one to the FILE-COUNT, resetting the TYPE-BYTE to match the fi the worst case the parts of the file which are forever lost are critical and the file itself could not be recovered with any reliability by any program. In the more likely case, THE RETRIEVER will facil deleted file have been reused by other files since the deletion. THIS SITUATION CAN NEVER OCCUR IF YOU RUN THE RETRIEVER IMMEDIATELY AFTER THE INADVERTENT DELETE. But in the real world this is not always the case. In the more likely case, THE RETRIEVER gives you enough information to allow a correct selection the first time. B. A situation where parts of the diskette containing data from your accidentallyieving . This situation may lead to some guesswork but at the worst you restore an old "worthless" file on a guess, recognize this fact, and go ahead and delete it and try THE RETRIEVER on another guess. In th suggestions for framing your decision making. Briefly summarized they are : A. A situation in which more than one entry is found by THE RETRIEVER for previously deleted files with the name you are retr are famous for and that the computer suffers a distinct shortage of. Thats why you bought the computer and not the other way around. These two circumstances are described at some length in the following pages together wiin which it processes file deletion and creation, you may encounter either of two anomalous situations during the retrieval process. Both of these require the type of "intelligent" decision analysis that you, Homo Sapiens,ETRIEVER will wend its way through the retrieval process and present you with nothing more than a "file successfully retrieved" message. Due, however, to the nature of the file handler system of the Apple III and of the manner D A DataSystems Appendix B ANOMALOUS SITUATIONS In the vast majority of cases, after entering the Pathname of the file you wish to retrieve, THE Rf the file...see the section describing "anomalous" situations. * * * -10- The Retriever ne or two blocks have since been taken over by another file) or permanently lost ( if the directory entry is over-written or all blocks are re-used). In the former case THE RETRIEVER may still assist you in recovering part oTFORWARD as long as you, or your Application have not gone on from your 'inadvertent' delete and added new files or expanded existing ones. Under these circumstances the information may be damaged in unpredictable ways (if o its list of block numbers. Other file types, e.g. subdirectories, require alternative formats for obtaining all the block numbers for the file.) UNFAIRLY CROOKED As you can see, this process is FAIRLY STRAIGHle, and finding the blocks used by the file and 'toggling' their associated bitmap bits. (If the file is a standard file this requires finding the pointer to the KEYBLOCK in the directory entry then reading in the keyblock withitate the partial retrieval of the file and you need only apply some later "massaging" to account for the lost data. * * * -11- The Retriever D A DataSystems ANOMOLOUS SITUATIONS A. MULTIPLE CANDIDATES FOR RETRIEVAL Under certain circumstances THE RETRIEVER will deviate from the staxxx .... 28 TESTFILExxxxxxx .... note the zeroing of the Type-Byte -13- The Retriever D A DataSystems (c TESTFILE with directory entries : 28 LASTMILExxxxxxx .... 28 TESTFILExxxxxxx .... (b) Having already gone the last mile, you delete the file LASTMILE 00 LASTMILExxxxwill in a minute. Name length is "A" which is hexadecimal for 10 (remember 1,2,3... 9,A,B,C,D,E,F). Storage-type is "3". * * * SCENARIO (a) You create two files called LASTMILE ander of the directory information (e.g. Keyblock pointer, create date/time. etc). thus 3A TESTFILE.Axxxxx .... represents the entry for the file "TESTFILE.A" with the x's standing for 'don't care'...although we NNNNN... the 15 character file name field. X and Y are stored as base-16, or hexadecimal, numbers and thus can hold values from 0 to 15 in one character, represented by 0-9, A,B,C,D,E,F. The "...." represents the remaindIN A PROBLEMATIC SCENARIO. WE WILL REPRESENT the type-byte and file-name part of a directory entry as XY NNNNNNNNNNNNNNN.... where X and Y represent the storage-type and name length nybbles respectively and the file-type byte... thus zeroing the name-length field. -12- The Retriever D A DataSystems SO, LETS PUT THESE TOGETHER te is called, trust me, a "nybble"). (b) As we mentioned in the "HOW IT WORKS" section, when SOS deletes a file, the only change it makes to the directory entry is to zero out both nybbles of to the length of that name. Trailing spaces in the file-name field are not overwritten with blanks or zeros because SOS keeps a record of the name length in one-half of the file-type byte (one-half by) SOS may re-use the 'slot' in the directory made available by a file deletion when it creates a new file. The 15 spaces reserved for file name are over-written with the characters of the new name up d TEMP1's will reside in different 'slots' of the directory and present themselves to THE RETRIEVER as match candidates. The more complex case arises because of two factors in the way SOS uses file directory entries. (a * * * In the simpler case this situation can arise if a file named, for example, TEMP1 is created and deleted repeatedly. If this is intermixed with other file create-delete activity the various delete given that SOS does not allow the creation of more than one file with the same name? We'll try to explain what precipitates this type of situation and give you some suggestions on making that choice, below. ndard "MATCH FOUND" message after successfully searching for a file and instead present you with a numbered list of possible retrievals one of which you must choose to continue with. How, you might ask, is this possible -) You now create a PASCAL test file but SOS won't allow another TESTFILE so you simply call it TESTF. SOS places the new directory entry in the available slot. 25 TESTFILExxxxxxx .... (TESTF entry - name length = 5) 28 TESTFILExxxxxxx .... Did that surprise you ? The "ILE" in the first entry is non-existent to SOS since is knows the length is 5 and only will check 5 characters able that limited file size dynamics would allow all the blocks in an incorrectly guessed file to still be free. In this case no harm is done if you retrieve it, look at it, and later re-delete or rename it to allow a later retriee above example only to be told that 9 of the 17 blocks allocated to the file have been re-used... clearly an old delete, not our freshly slaughtered TESTFILE...quit at the Bitmap Fault and re-run selecting #1. It is conceiv this block re-allocated situation, which we call a BITMAP FAULT, and allow you to QUIT then with no changes. You can, in other words, guess. * * * You might choose #3 in thnew file; files deleted quite a bit previously probably will have had many of the allocated blocks re-used. If you ask THE RETRIEVER to retrieve the latter it will warn you when it encounters age of your own recently acquired knowledge of the APPLE III deletion process (see the previous 'How It Works' section). The disk space allocated to files just deleted can not have been re-used by a ou are after a BASIC data file created a while back,but not 6 months ago, and just deleted - you choose #2 by typing 2 . (c) If you are a bit uncertain about dates, you can take advanton your own knowledge of the history of use of the disk or application, select the genuine TESTFILE for retrieval. In the example above this is reasonably straightforward if you recall that y D A DataSystems CREATIVE RESPONSE At this point you have three options. (a) Copy down the information and Quit now to review the facts by typing Q as instructed. (b) Based up 2 TESTFILEerfiles 10/10/83 01/15/84 Pascal Code 3 TESTFILE.june.. 06/06/83 09/11/83 Basic Data -14- The Retriever he meaningful alphabetic parts of the remainder of the file name field. It looks like the following : Number File Name Created Deleted Type 1 TESTFILEccounts 09/09/83 01/15/84 Basic Data oices, that's still your domain. THE RETRIEVER assists you by listing each together with certain information available about the deleted file, specifically file TYPE and CREATION DATE, and it capitalizes the SEARCH NAME but lists t TESTFILE from ... 00 TESTFILECCOUNTS .... 00 TESTFILEERFILES .... 00 TESTFILE.JUNE#% .... YOU CAN SEE THE PROBLEM...This situation requires creative intelligence to sort out the ch 00 TESTFILExxxxxxx .... (e) Throw in a third, previously deleted, file which was named TESTFILE.JUNE and put some random meat, from previous uses, on the xxx's and then ask THE RETRIEVER to retrieve when performing a search of the directory. (d) Now, naturally, you cooperate with the demonstration by deleting TESTF...and, ACCIDENTALLY DELETING TESTFILE !! 00 TESTFILExxxxxxx .... val of another guess. YOU MUST SUPPLY THE 'THINKING' HERE... don't panic, remember option (a). -15- The Retriever D A DataSystems ANOMALOUS SITUATIONS B. DISK SPACE RESERVED FOR THE DELETED FILE HAS BEEN RE-USED BY OTHER FILES SINCE THE DELETION - "BITMAP FAULTS" IF YOU ACCIDENTALLY DELETE A FILE... you reac do the patching. The general approach will be to read and write known data structures until an error occurs then to skip on reading until back in sync then continue read-write. * * * Worst ca * * * You will need some familiarity with the structures of different types of SOS files (e.g. BASIC data files, BASIC text files, PASCAL code files) and probably a "one-shot" CLEANUP program to, that the next 52 characters are a basic 'string' datum. If that imbedded character or the 50 character count are altered by a block fault, patching the preceeding and next blocks together leaves everything out of sync. some time in the recovery room. Very few of your applications or languages store their data in neat 512 byte blocks, the loss of one of which can be stepped over. Many languages imbed markers in the data identifying, for exampled out... certainly not at the expense of a 2.5 meg master file. But you must recognize that pulling a random block out of a file is a bit like surgery with pliers. Sometimes its just not advisable, other times you should plan on -16- The Retriever D A DataSystems SURGERY WITH PLIERS The preceeding is not meant to imply that retrieval of part of the file should be rule OUT OF y BLOCKS allocated to the file have been lost...do you wish to continue ?" This decision involves the type of ambivalence that computers are not the slightest bit competent at... you still have a function. for each block listed in your deleted file's keyblock and finds that the bit is not, as expected, set. These blocks are tallied and stored until all bits are checked. At this point you are warned by a message to the effect that "x also updates the aggressor file's Keyblock with the block number. WHAT'S A DOG TO DO ? Now if you ask THE RETRIEVER to retrieve the former file, the program logic detects this situation when it checks the bitmap entry or expanding file is uses one marked as free in the bitmap. But this could well be part of your 'inadvertently' deleted file. Unaware of your plight, SOS writes the new data out to the block and clears the bit to mark it 'taken'; it n though they still contain YOUR DATA. This is because the delete process sets certain bits associated with the deleted file in a special group of disk blocks called the Bitmap or Diskmap. If SOS needs another block for a neween lost - do you wish to continue ?" HOW IT HAPPENED Once you or your application program delete a file SOS effectively considers the disk blocks previously allocated to that file to be free for other use; eve?), which continues on for a bit updating other files and creating new ones. THE RETRIEVER may expose its imperfect underbelly to you with interesting messages like : "4 out of 1237 blocks allocated to the file have bh for THE RETRIEVER. That's natural once you've got the tool at hand. But what if you don't notice the situation until the end of the day? Or what if the delete was done by a less-than-perfect application (you mean they're not se could be deletion of a Program File since BASIC programs, for example, store pointers to the next program line in the disk data. If we get out of sync, as we almost certainly will, the BASIC language will see part of your program as an impossible large or unlikely pointer and look ahead 5000 bytes in memory for the next line...makes for very interesting listings. Best case would be, for example, a BASIC data file storing only 62-byte character sSystems BITMAP FAULT DECISIONS THE RETRIEVER WILL MAKE If the deleted & overwritten ('faulted') file was storage type 1, which uses only one disk block anyway, THE RETRIEVER will terminate with an error meTRIEVAL ALWAYS CLEANUP YOUR FILE IF RETRIEVAL ENCOUNTERED BLOCK FAULTS. * * * -18- The Retriever D A DataTO NOTICE WHAT YOU'RE DOING AND NOT TO FOOL AROUND ONCE YOU RECOGNIZE THAT YOU'VE JUST CLOBBERED YOUR MASTER FILE. GET TO THE RETRIEVER AS QUICKLY AS YOU CAN SHORT OF PULLING THE PLUG ON YOUR MACHINE. ALWAYS REVIEW YOUR FILE AFTER RE down the hierarchy of unlikelyhood here, you should keep in mind these possibilities if you ever start to take too much for granted the power of THE RETRIEVER. * * * THE MORAL IS THE RETRIEVER will check the bitmap for each, producing either suspicious "block fault" messages or, conceivably, a successfully retrieved mixed collection of random and correct data. Although we've traipsed quite a wayr 13 will terminate. (3) In the more slippery case of (2) above the random numbers in the fraudulent double-faulted keyblock (now thats something to call your favorite politician) will seem legitimate and used by THE RETRIEVER as representing a list of block numbers of the data in the file to be retrieved. In the most likely case these numbers will be identified by exception logic in the program as being incorrectly large and an errogone. Three things can happen... (1) In retrieving this 'double-faulted' block you pick up random and irrelevant data. (2) If the d-f block is thought to be a keyblock the random data in it will beour original file...then delete the second file intentionally - leaving the bitmap bit for the block in question set. Just what THE RETRIEVER expects to see for a free, unfaulted block. But in this case your data is long D A DataSystems IMPERFECT UNDERBELLY AGAIN Think really devious thoughts for a minute. What if you go ahead and inadvertently delete that file... expand another file so it uses a block associated with y value out of the middle of your 'plier wound' in the file and you will have started the data file equivalent of a brush fire. -17- The Retriever g the 'partially' retrieved file with no problems since the majority of your I/O on the file will be away from the scar. But one day your application will ask for the index pointer entry for item 35-X and return a peculiar ot found or, more mysteriously, 'end of file' message. In either case you can allow for the gap. In any case DON'T IGNORE THE NEED FOR THIS CLEANUP. You can pull one block out of a huge file then go blithely back to usintrings. Since each is attached to a 2-byte 'descriptor' (see Apple Basic Manual) we fit a fixed, neat 8 64-byte items in each block. The retrieved data structure is coherent and attempts to access the faulted data will give a nssage. If the faulted block was a file keyblock, which contains the numbers of all the other blocks used by the file, THE RETRIEVER will terminate with an error message. If the faulted file was storage type 3, (over 128,000 bytes) - the keyblock points to other lower level keyblocks called 'index' blocks), a faulted index block is effectively the same problem as above, up to 128 blocks, or 65536 bytes of data may be trieved. Check your spelling and re-enter ERROR 4 Pathname must begin with a "." You must enter the full pathname of the file you wish to retrieve, commencing with the device name part of tTESTF was found on .D1 in the MYSUB subdirectory. Check your spelling and re-enter. ERROR 3 A File by that name ALREADY EXISTS !! THE RETRIEVER found an active occurrence of the file you've named to be renot found at all or was deleted (remember, in this case we're trying to retrieve TESTF). If 'xxxx' was the lowest level (e.g. TESTF) the error indicates that no deleted occurrence of R was unable to find an appropriate directory entry for 'xxxxx'. If this was a higher level of a pathname (e.g. 'MYSUB' in the pathname .D1/MYSUB/TESTF) the error indicates that the name MYSUB was either D A DataSystems Appendix C MESSAGES and ERROR REPORTS ERROR 1 This code not currently used ERROR 2 Name 'xxxxxxxxx' NOT FOUND THE RETRIEVE THE RETRIEVER to help make a dreadful situation at least tolerable. * * * -20- The Retriever In the case that you probably bought THE RETRIEVER to insure against, deletion of a large, critical file with poor backup and no audit trail, AND BITMAP ERRORS (which you probably wish you'd never heard of) you'll probably usen capacity to create a one-shot to clean it up. Consider contract programming costs for this if your own skills in this area aren't up to the task. For programs check for backup disks or call the software house...or buy another. s down to. Consider the state of your backups. A very old backup is effectively data lost. Depending upon your audit trail, updating the old backup may range from simple to impossible. Consider the type of data lost and your ow -19- The Retriever D A DataSystems THE DECISION YOU MUST MAKE Costs versus Benefits is,naturally, what it boilts beginning, the number of the preceeding and next blocks in the file. If this 'linked list' chain is broken, THE RETRIEVER will have no way of determining the remaining block numbers. * * * file is a subdirectory THE RETRIEVER will terminate with an error message.. This is because the block numbers of a subdirectory file are not saved in a keyblock somewhere; each subdirectory file disk block has stored, at i idea here is that the time-cost required to rebuild a retrieved but extremely fragmented file begins to exceed any benefits. See SPECIAL USER NOTES about increasing the limit if you're desperate. If the faulted unretrievable; THE RETRIEVER will terminate with an error message. If the fault count exceeds a maximum limit internal to the program (currently set to 20), THE RETRIEVER will terminate with an error message.. The generalhe pathname. Device names always begin with a "." such as .D1, .Profile, .MSCI1 - see your Owners Guide pp 29-30. Check your spelling and re-enter ERROR 5 Device 'xxxxxxxx' NOT FOUND... The Device you have specified is not configured into your system. Either you have incorrectly specified the device (e.g. .D11 or .Porfile) or you are attempting to access a device which is not incluT CONTINUE A block number contained in the expected Keyblock exceeds the number of blocks on the volume. The assumption is that the keyblock was previously overwritten then freed. The segmented. If you critically need to override this nn value and feel you can patch up the pieces retrieved, see the section of Special User Notes. ERROR 13 KEYBLOCK for your file is scrambled CANNOximum of nn Blocks previously allocated to your Inadvertently Deleted file have been overwritten by other files since the deletion.. The file, if partially retrieved, would be confusingly D A DataSystems ERROR 12 BITMAP ERROR More than nn bitmap faults encountered file is largely irretrievable...CANNOT CONTINUE More than the internally defined ma Inadvertently Deleted was only one block long and that block has been overwritten on the disk. The file must be restored from backup. -22- The Retriever rwritten by another file. The file must be restored from backup. ERROR 11 BITMAP ERROR For Storage Type 1... The Single Block allocated to this file has been re-used CANNOT CONTINUE The p. ERROR 10 BITMAP ERROR for File KEYBLOCK... CANNOT CONTINUE The block which contains the numbers of all the other blocks of your Inadvertently Deleted file has been ovebers of the blocks containing up to 65000 characters of your file. THE RETRIEVER will never be able to find these blocks so the Retrieval process is halted. The file must be restored from backulocks previously allocated to your Inadvertently Deleted file has been used by another file since the deletion. Unfortunately that block is a critical, so-called 'index' block which contains the numen done. No files or information is altered on any device. ERROR 9 BITMAP ERROR for Storage Type 3... Index block of file has been reused file is largely irretrievable...CANNOT CONTINUE One of the b or unusual characters. ERROR 7 This code not currently used ERROR 8 Voluntary termination ... You have chosen to exit THE RETRIEVER prior to completion of the Retrieval process. No retrieval has be D A DataSystems ERROR 6 Invalid PATHNAME... Something about the pathname you have entered is not valid. See your owners guide pp 31-38. Check for imbedded spaces using your System Utilities Diskette System Configuration Program (SCP). In the former case, Check your spelling and re-enter -21- The Retriever ded in the SOS.DRIVER file supplied with THE RETRIEVER. (e.g. a second supplier Hard Disk). In the latter case you must add the driver for the device to the SOS.DRIVER file on the RETRIEVER diskette file must be restored from backup. ERROR 14 BITMAP ERROR for SUBDIRECTORY FILE... CANNOT CONTINUE The block numbers of a subdirectory file are not all stored in one place in a keyblock; each block of the file contains the number of the preceeding and next block, if any of these is overwritten you will get this message since the rest of the chain of blocks is undeterminable. For all -24- The Retriever D A DataSystems Status Messages re Bitmap I/O : Reading BITMAP from BLOCK # nn Writing out BITMAP BLOCK # nn Tted, drives on and doors closed then retry the retrieval. If the condition persists feel free to contact D A Datasystems for followup and diagnostic assistance. f THE RETRIEVER has stumbled upon an unexpected error condition. Please copy down the error number nn and line number ll for reference. Verify that all diskettes are properly inser to do a COPY on the file counting on clean keyblocks, etc or restore from backup. ERROR 25 UNEXPECTED PROGRAM ERROR # nn in LINE # ll This messages indicates that the internal program logic oernal data value must be in error so safest to terminate now. The file will be back in the directory but failure to update the bitmap leaves its blocks subject to overwriting. You might try VER in attempting to update a bit in the bitmap to mark a block as used by your newly retrieved file, finds the bit already clear but the block is not one previously identified as overwritten. Somewhere an int be cleared is already clear Bitmap pointers apparently out of sync - Unable to continue FILE PARTIALLY RECOVERED Theoretically impossible but... so was deleting that master file, right. THE RETRIEs directory out of sync. This is quite unlikely since all of the involved disk blocks will have been previously read in and a flawed block would be hit then. ERROR 22 BITMAP ERROR - Bit toriting takes place at the end of THE RETRIEVER during the update functions you might end up with certain values updated (e.g. file count and delete flag) but others not updated (e.g. bitmap), and thuterminated . ERROR 21 Recurring DISK ERROR during WRITE access FATAL ERROR... program terminated Similar to ERROR 20 except error is during attempts to write. Note that since wROR... program terminated One block on your diskette or hard disk cannot be read after repeated attempts by THE RETRIEVER. Since the needed information is not available the Retrieval is ion as ERROR 14. -23- The Retriever D A DataSystems ERROR 20 Recurring DISK ERROR during READ access FATAL ERry block numbers appears garbled. Prior reuse of one of the blocks in the chain may have left it apparently free but actually containing new and invalid data. In any case, this is effectively the same situat practical purposes a subdirectory file cannot be retrieved if it has been partially overwritten (block faulted). ERROR 15 SUBDIRECTORY Pointer Chain GARBLED... CANNOT CONTINUE The chain of subdirectohese messages specify the block or blocks being accessed with bitmap data. Status Messages re Disk I/O : Reading in disk BLOCK # nn Writing out disk BLOCK # nn These messages specify the block being accessed by THE RETRIEVER as it goes about its business. Error Messages re Disk I/O : (retry up to 3 times) ERROR READING BLOCK # nn WILL RETRY ERROR WRITING BLOCK # nn WILL RETRY RY OF TERMS BITMAP A reserved section of a SOS formatted diskette which contains a number of 8-bit bytes sufficient to allow one bit for each 512 byte block of storage space on THE RETRIEVER is ended. -26- The Retriever D A DataSystems Appendix D GLOSSA bitmap associated with each retrievable block of your file to re-establish their usage by your retrieved file and prevent any other SOS use of the blocks. Terminate Pgm counter of files stored in the directory containing your retrieved file to allow for its undeletion. Update Bitmap THE RETRIEVER is setting to '0' value the bits in the file. Update DEL Flag THE RETRIEVER is updating the zeroed out type-byte of the file to re-establish its existence in the directory. Update File Count THE RETRIEVER is adding one to the function. Check Bitmap THE RETRIEVER is checking each block assigned to your file to verify that the bitmap indicates that is has not been re-allocated to another representing files with, respectively, 0-512, 513-131072, 131073+ total bytes. Since each storage type is handled differently by SOS disk/file management, this is a critical subdirectories and for the file name you specified for retrieval. Get Storage Type THE RETRIEVER is determining whether the file is a subdirectory or storage type 1, 2, or 3 - Bitmap THE RETRIEVER is reading the entire diskmap or Bitmap from the disk to be used for all later processing. Search for File THE RETRIEVER is searching for each of the e File Name THE RETRIEVER is breaking the pathname down into separate device name and various subdirectory names (if any) and the actual file name to be searched for. Read inn. They are listed in screen window (d) and the current function is highlighted. Get File Name THE RETRIEVER is waiting for you to key in the pathname of the file that you want to retrieve. Pars -25- The Retriever D A DataSystems CURRENT FUNCTIONS These 10 program functions of THE RETRIEVER occur in successiotifies a Block fault condition and goes on to outline your alternatives and to prompt for a decision regarding partial recovery. See the section of this manual describing Anomalous Situations - Bitmap Faults. These messages indicate a problem with either the disk drive hardware or the diskette or hard disk media itself. Block Fault message : File Damaged by Disk Activity since Deletion ... This message identhe disk. The bits are set to '0' if the associated block is used by a file, '1' if the block is free. BLOCK A name given to a logical section of a SOS disk which holds 512 bytes of data. BLOCK FAULT A situation wherein a block previously allocated to your deleted file has since been reused by another new or expanding file. DIRECTORY A section of a disk which serves as a Table of OS Reference Manual vol 1. How SOS Works vol 2. The SOS Calls Apple Computer & Don Reed Available now from most dealers See esp. Vol.1 - chapter 5 "File Organization on Block available for re-use by another new file. -28- The Retriever D A DataSystems REFERENCES Apple III S resources such as main memory. TYPE-BYTE The first byte of a directory entry for a file which is zeroed out when the file is deleted. This indicates to SOS that the 'slot' of the directory is th a new device. SOS Sophisticated Operating System. The system software which runs the Apple III. Manages all devices,information in the form of files, and iguration Program. The Apple III supplied utility program which allows the addition, deletion or alteration of a Device Driver to the SOS.DRIVER file... allowing the Apple III to communicate wi a given device. STORAGE TYPE Specification of file size or structure. Small, medium, or large or subdirectory. See keyblock, index block, linked list. SCP System Confbyte. Four bits of information. PATHNAME The complete designation of a file name within the hierarchical file structure of SOS containing up to 128 characters multiple levels of subdirectories on ointer' information locating the previous and/or next items in the list. In Apple III SOS subdirectory files are stored as 'doubly-linked' lists of data blocks. NYBBLE One-Half -27- The Retriever D A DataSystems Glossary Continued LINKED LIST A collection of data wherein each item carries with it 'p Instead is contains a list of the numbers of the blocks that do contain the data. For larger files the keyblock contains the numbers of the files' Index BLocks. the Keyblock. For storage type = 1 files (less than 513 bytes long) this block is the sole data block. For storage type = 2 (513 - 128K bytes) this block contains no actual data. e block numbers used by the actual file data. KEYBLOCK The directory entry of any file contains, among other pieces of information, the block number of a block on the disk which is 128K bytes), the Keyblock does not contain the numbers of each block used by the file; instead it contains the numbers of the Index Blocks of the file which, in turn, contain lists of th Contents to the files on a disk or, in the case or a subdirectory, to a logically related grouping of files. INDEX BLOCK For very large files (storage type = 3, more than Devices" Apple III Owners Guide by Apple Computer See esp. chapter 3 "The Operating System" re pathnames chapter 4 "The Utilities Diskette" re the SCP chapter 5 "The Filer" re deleting files glossary on pages 155-163 Apple III Pascal Introduction, Filer, and Editor by Apple Computer See esp. chapter 3 "The Filer" pp 68-69 re deleting files. Apple III Business BA, ITS MERCHANTABILITY OR ITS FITNESS FOR ANY PARTICULAR PURPOSE. THE EXCLUSION OF IMPLIED WARRANTIES IS NOT PERMITTED IN SOME STATES. THE ABOVE EXCLUSION MAY NOT APPLY TO YOU. THIS WARRANTY PROVIDES YOU WITH SPECIFIC LEGAL Rhout notice. The word Apple is a registered trademark of Apple Computer. * * * APPLE COMPUTER, INC. MAKES NO WARRANTIES, EITHER EXPRESS OR IMPLIED, REGARDING THE ENCLOSED COMPUTER SOFTWARE PACKAGEability for incidental or consequential damages, so the above limitation or exclusion may not apply to you. D A DATASYSTEMS reserves the right to make improvements in the product described in this manual at any time and witor consequential damages resulting from any defect in the software, even if D A DATASYSTEMS has been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of implied warranties or li its distributors or retailers) assumes the entire cost of all necessary servicing, repair, or correction and any incidental or consequential damages. In no event will D A DATASYSTEMS be liable for direct, indirect, incidental, . D A DATASYSTEMS software is sold or licensed "as is". The entire risk as to its quality and performance is with the buyer. Should the programs prove defective following their purchase, the buyer (and not D A DATASYSTEMS, D A DATASYSTEMS makes no warranties, either express or implied, with respect to this manual or with respect to the software described in this manual, its quality, performance, merchantability, or fitness for any particular purposentil THE RETRIEVER is re-booted. -30- The Retriever D A DataSystems DISCLAIMER OF ALL WARRANTIES AND LIABILITIES periods or other characters; if you receive an error message you have mis-typed it. You will then be re-prompted for the Pathname and processing will continue. This new maximum will remain in effect until changed again or uor the PATHNAME of the file to be retrieved type in : EMAX=nnn where nnn is a number representing your new maximum block fault count. examples: EMAX=35 EMAX=100 No spaces, gmentation will cause more problems down the road than it solves. But if you're desperate (restoring a 3 meg file with no backup at all available), we do allow this maximum to be altered temporarily . When prompted f20 block faults on a file, representing 10,240 bytes of lost data, before terminating with an error message. This reflects our belief that partially restoring a file with a greater quantity of lost data and greater se D A DataSystems Appendix E SPECIAL USER NOTES, INCREASING THE MAXIMUM NUMBER OF BLOCK FAULTS ALLOWED. Normally THE RETRIEVER allows up to SIC Reference Manual 2 vols See esp. Vol 1 - chapter 5 "File I/O" pg 134 re deleting files. -29- The Retriever IGHTS. THERE MAY BE OTHER RIGHTS THAT YOU MAY HAVE WHICH VARY FROM STATE TO STATE. -31- END ves the right to make improvements in the product described in this manual at any time and 0 WAP /// SIG MENU.MAKER PROGRAM (v. 6.2) =".D1"210: Coldstart (320: Warmstart &*X=11000: TEXT SLOW-DOWN LOOP ,X.1 CHANGE DISK SUBROUTINE23œ202:2200<RFa$=" YOU MAY SELECT YOUR DISK BY M$="NOVEMBER":1750M$="DECEMBER":1750826);"-";M$;" ";Ѡ,2));", ";"19";Р,2);" ";/П,2))=>13П,2))-12;џ,6);:1780$П,2))=0"12";џ,6);:ٟ;$П,2))=>12" PM-":" AM-" 1830WW=1530 =26:=211660,1670,1680,1690,1700,1710,1720,1730,1740^M$="JANUARY":1750hM$="FEBRUARY":1750rM$="MARCH":1750|M$="APRIL":1750M$="MAY":1750M$="JUNE":1750M$="JULY":1750M$="AUGUST":1750M$="SEPTEMBER":1750M$="OCTOBER":1750T 0")2070H540R\A$="RUNNING "+B$(I),16,B)f"79C";A$;:=0pB$(I),16,B) z::SEG=1".D1/SEG.T"t=+B$(I),16,B) yCT=CT+1~240:=24:=0:"@ ..... "DATE.TIME.LINE" ....JM=Ҡ,4,2))BTM1630,1640,1650,0=+IBOTM/2-.5):I=IBOTM:I/2=I/2)I=I-1 œ2120B=B$(I),16)," ")-1 B$(I),"BASIC 0")850B$(I),"TEXT 0")890 B$(I),"CAT 0")1140*B$(I),"FONT 0")18504B$(I),"FOTO 0")1930>B$(I),"PASTXB$(I);v:520: 500THPOS=4:I/2=I/2)I=I-1I=IBOTM THPOS=44:I/2<>I/2)I=I+1I2=-1:I=I-2:IBOTM<30THPOS=44I=IBOTM/2)*2:=+IBOTM/2)-1:CA)"PRINT.ALL": OA+P 3HA=(81+UCA)A=(81+LCA):::: OA+Q Quits 3IA=(83+LCA)A=(83+UCA)"PRINT.SHOW": OA+S 2JA=(68+LCA)A=(68+UCA)/Screen.Savers/HELLON=THPOS:B$(I);XA<8A>11540bA-7640,660,690,720l:=THPOS:ٺ1600 =Q:WW=0A=:A=21A=9&oldprefix$=40A=31410: Control C "aborts" program to Basic(:A=13770: Return Selects a file *DA=27:50: Escape to change disks/FA=324000: back out one directory level 3GA=(80+UCA)A=(80+L"BASIC 0":150A$="TEXT 0":150A$="CAT 0":150A$="FONT 0":150A$="FOTO 0":150A$(L),"BLOCKS")510*=27:=19:"FREE MEMORY AVAILABLE: ";=7:=20:"80C";A$(L);$:=5:THPOS=4:I=1:IBOTM=J-1:620Q=:=26:=21:sic; +Q Quits."r12);::"80C";a$;:+w#9,"DISKNAME.DAT":#9;DISKNAME$:#9|d$=DISKNAME$$=23:=0::"80C";d$;::12)201M=3:=14:"This /// SIG Disk is \^ 19";Р,2)", Washington Apple `, Ltd."=4:B$(1)="":B$(2)=""A$=16,B) THEN 240 #1, d$="":=10:"80C";d$ ž#1300I=0"I=I+1:#1;A$(I):290,#1 6L=I-1@j=1:same=0 J:SEG=0 Tœ2030^CT<1CT=1cCT>13000Zha$="{,|,~,}; selects; to new disk; J/2)=4:=+1:ۙ=44B$(J);:J=J+1I:1,180,22:2,280,21:2,2380,23:8A$(1000),B$(1000),C%(511),C$(20),name$(20):=10:=0UCA=128:LCA=UCA+32CT=15 IF PREFIX$= PREFIX$+MID$(B$(I),VOLUME NAME (/DISKNAME) OR DEVICE NAME (.Dx)"P12);::"80C";a$;:Zb$="CHANGING DISKS"$d=23:=0::"80C";b$;::12).n=12:=20:"MAKE A NEW MENU FOR DISK: ";N$xN$)<2110=N$ :210 I=1L(A$(I),A$))200B$ 1600 &:WW=1:0 :SEG=1;".D1/S EG.F" SEG=1".D1/SEG.G"diskname$=3802  CATCH PASCAL TEXT FILES 202 :F*=08:"78C";"SORRY BUT MENU.MAKER CAN'T READ PASCAL TEXT FILES."04=10:"78C";"ANY KEY RETURNS TO THE MENU.">G$:::320H: Error Routine 202:U=11:"79C";"BAD PATH ERROR (NO DISK IN DISK DRIVE OR DESIRED FILE NOT FOUND.)"X=11000:X:::210Z a$="{,|,~,}; selects; back 1 levp$ 900A$="PRINTING"+F$(I):$=01:=0::"80C";A$;::12)F=23:=0::"79C";"PRESS ANY KEY TO HALT PRINTING"::2,280,21 2000*:=23:=0::"79C";"CONTINUE...?":1C$:C$<>"Y"C$<>"y"C$<>"N"C$<>"n"#1,D$::"Processing directory ";34);D$;34);", please wait."; ž#1880*#1;A$:A$)<48104A$,3,4)<>"TEXT"810>X=X+1:".";HE=15:F$=A$,16,15)RF$,E,1)=" "E=E-1:850\F$(X)=D$+"/"+F$,E)f810p:  Pausež#1740#1;A$:A$)<4710A$,3,4)="TEXT"X=X+1710 :X>YN=P::7);"There are no text files in the ";34);D$;34);" directory." ::I=P::7);"Unable to locate and open ";34);D$;34);" directory." ::IT$=N$,E,1):T$=" "T$=","610XE=E+1:E>N$)610:590bD$=N$,S,E-S)l:v:E>S+1600:D$="": œ770P=3:"Looking for ";34);D$;34);" directory." #1,D$=P3:"Reading from ";34);D$;34);" directory." I>X200300S=1:D=1:B=1570D$=""500 Y=X:S=ED$(D)=D$:640 X=Y440D=D+1:S=E:440D=D-1:X=0F$(X):X=0 J=1D D$=D$(J)790&J0 :œ6303DE=S+1:N$,S,1)=" "N$,S,1)=","S=S+1:580%Nž#2390 ^1000c: h#2;a$ma$rY=1150:Y0wB=B+1: Count the number of lines printed xB=15B=30355yB=60#3;12)zB=60B=1 {#3;a$|360B<=20#3;13)::410#3;12):Z=11000:ZI I=3d: PRINTER V. 1.0 ::=2::"PRINT.ALL v. 1.0":3=4:"Directory Name(s) or return to quit: ";n$N$)=0::"MENU.MAKER"430 X>0260I=11000:I:200: ,I=1X 14000 6#2,F$(I)@#3,".PRINTER" JTHE RETRIEVER BY DARYL ANDERSON a$,1)="/"5060:s=s-1 5030=a$240 MENU.MAKER 6.2 * Thanks to C.M.Davidson for his help!el; =23:=0::"EAD PASCAL TEXT FILES."04=10:"78C";"ANY KEY RETURNS TO THE MENU."!>G$:::".D1/MENU.MAKER",320R",220(204::"79A";""; 2D=1:F=1 <#4;a$ FD=D+1 P#5;a$ZD=60#5;12)dD=60D=1nF=F+1::d$;::Y=1100:Y x13402  CATCH PASCAL TEXT FILES 202 :F*=08:"78C";"SORRY BUT MENU.MAKER CAN'T R".D1/MENU.MAKER",220 d$="" A$="PRINTING "+B$(I),16,B)=01:=0::"80C";A$;:#3,B$(I),16,B)Z=1#3;b$:"78A";b$Z=Z+1:Z=18:1290 1260 #4,B$(I),16,B)#5,".PRINTER"+ž#4#5;12):::".D1/MENU.MAKE30C$="N"C$="n"1160;:=23:=0::"79C";"PRESS ANY KEY TO HALT LISTING": $1020.202 8::Z=1B::=23:=0::"79C";"WOULD YOU LIKE A PRINTED COPY?":1C$:C$<>"Y"C$<>"y"C$<>"N"C$<>"n"1170*C$="N"C$="n"79C";"PRESS ANY KEY TO HALT LISTING"::202 1020#2,B$(I),16,B)ž#242:::1160Z=1#2;A$:"78A";A$Z=Z+1:Z>1842:::Z=1980*:=23:=0::"79C";"CONTINUE...?":1C$:C$<>"Y"C$<>"y"C$<>"N"C$<>"n"10