Oakland CPM Archive

home *** CD-ROM | disk | FTP | other *** search

/ Oakland CPM Archive / oakcpm.iso / cpm / dirutl / setdru.azt / SETDRU.ART

Wrap

Text File | 1987-10-21 | 17.0 KB | 351 lines

FURTHER ADVENTURES WITH CORRECT-IT: Z80DOS, PUBLIC FILES AND SETDRU - or - 'WHERE'D THAT FILE COME FROM?' by Rick Charnes San Francisco, Oct. 18, 1987 Hooray - I've cracked the code! ... Ever notice how sometimes the most valuable lessons in life come from errors you've made? * * * For the last several days I've been been using fellow Morrow owner and programmer par excellence Carson Wilson's new operating system, Z80DOS. This new BDOS for Z80 computers provides full datestamping (and time-stamping, if a real time clock is present) integrated in to the directory. ZRDOS, the BDOS used with the "official" Z-System has no internal datestamping, so it is therefore generally done via an external program, DateStamper. DateStamper, however, is fully compatible with Z80DOS and one can quite readily have both date/time-stamping environments simultaneously operative and this is indeed how I have arranged my system. I have been running the two side by side with no problem for several days. (I will henceforth refer to "date and time-stamping, if a real time clock is present" as simply "datestamping.) The original CP/M BDOS of course has no datestamping. Since historically CP/M programmers had no OS support the utiltiies they developed almost without exception were without datestamping. Although there are now several other CP/M replacements that do have datestamping -- QP/M, DOS+, SUPERDOS and P2DOS noteworthy among them -- we have had a situation where there was scarcely anything in software we could do with their datestamps save for running the small number of utilities supplied with them! In addition, a fairly sophisticated programming protocol was necessary in order to incorporate datestamping into the various CP/M utilities and applications. There certainly has been no standard. This has indirectly been the weakness of all previously existing date/time-stamping CP/M BDOS replacements. This is of course in marked contrast to the MS-DOS world where to my knowledge all programs are integrated with a datestamping system built into the OS. Z80DOS, however, does its datestamping by implementing two new BDOS functions exclusive to Z80DOS which allow programs that modify or copy files to maintain file date and time stamps with very little programming overhead. It does this in a way that none of the above BDOS'es or even DateStamper can do. This means that programmers can include datestamping support in new progams, or -- significantly, add it to existing programs -- with very little difficulty or extra code. Because of this ease of programming we now have great potential for creating a standard. One major advantage of this for me has been the existence of a utility supplied with Z80DOS -- a counterpart for which exists for none of the other systems -- that uses these new functions to enable a user to do something that I have missed sorely: the retention over successive editings of the 'date of creation' stamp of a word-processed file. (In all systems the 'date of last modification' stamp is of course renewed and changed accordingly.) Because of the way CP/M word processors modify files, on all other CP/M-compatible datestamping systems when a word-processed file is edited and modified the date of creation stamp suddenly becomes the same as the date of modification! This new feature, by the way, in my opinion makes Z80DOS' datestamping system superior to that of MS-DOS which does not have a function for 'date of creation' at all but rather only for last update. I commend Z80DOS to all CP/M users and urge all interested parties to investigate its superlative features. It is in the public domain and may be found on BBS's as Z80DOS10.LBR. * * * But this isn't why I'm excited. One of the other features of Z80DOS is its implementation of a sytem whereby certain files, usually overlays and the like, can be made available from all user areas in a drive. These files are then considered 'public'. Some provision of this sort is implemented in most of the CP/M 2.2 enhancements, including CP/M 3.0 and ZRDOS. In different systems it is implemented in different ways. With ZRDOS one has 'public directories' wherein any file residing inside that directory is automatically made public. With Z80DOS one sets the file attribute bit of the second character of the filename. For all intents and purposes the net result is the same. I have been using the public directory feature of ZRDOS for the year and a quarter I've been using ZCPR3. One of the programs for which on a hard disk it is quite literally indispensable is the Morrow spell-checker Correct- It. Without some sort of public file feature one can only run Correct-It from a single user area -- unless, that is, one has a copy of the 96k DICT.BIN, the 2k DINDEX.BIN and the 24k FIXUP.COM on each and every user area on one's hard disk! As implemented in most BDOS's including Echelon's ZRDOS, however, there is one danger to something as powerful as this 'public' feature. Erasing, or even simply creating, writing to or copying a non-public file with the same name as a public file erases the public file! Needless to say this can be quite disconcerting and if you don't know what's going on trying to trace the cause of your misfortune can be extremely frustrating. Z80DOS comes equipped with a safety feature to deal with this problem. A public file can only be erased if it is in the currently logged user area. Otherwise a read-only error is considered to have occurred. But I didn't know all this at the time. I was sitting pretty correcting a file one day, my mind as far away as could be from public files, safety features and the like -- and I got hit with my first R/O error message. I couldn't figure out what was happening. I was running my CORRECT- IT alias that I had always used with ZRDOS; what could be different this time? And to make things worse, when the error message displayed on the sceen it mentioned something about a file called 'XXPED.$$$'. What the heck was that and what was going on? It took me a couple of times running the alias before I realized that something that was happening was probably related to this public file safety feature. I then recalled how ZRDOS worked with this alias (previously released in my CORREC10.LBR). One must have AUXDICT.TXT, DICT.BIN, DINDEX.BIN and FIXUP.COM all in the public directory area, thus making them public files. But it does something else: when FIXUP.COM writes your newly "learned" words to your old AUXDICT.TXT, one eventually notices to one's distress that it ends up putting the resultant file not back in the public directory area where it must be located at alias invocation but rather in the currently logged user area! I have since figured out that what happens is similar to how all CP/M word processor work when they modify ("write to") a presently-existing file. A new file is created with a temporary name, the old one is erased, then the new is renamed to the old. (This, by the way, is why datestamping systems have such difficulty maintaining the time/date stamp of a word-processed file: they're essentially working with a new file. Once the original file is erased the new file has no way of knowing what the old file's creation date was.) So ZRDOS' public feature finds AUXDICT.TXT since it's in a public directory, opens it and reads its contents, and proceeds to create a new file with a temporary name. Since we're probably not logged on the public directory this new file is written to the currently logged user area. When that is done FIXUP.COM looks again to AUXDICT.TXT, still a public file, and erases it. Finally the temporary file residing on the currently logged user area is renamed to AUXDICT.TXT and no one is any the wiser. This worked fine with ZRDOS. The only drawback is that at alias exit we were then left with an AUXDICT.TXT that was no longer in a public directory, not a public file and therefore inaccessible to the next run of CORRECT-IT. So I dealt with this problem easily by putting one more command at the end of the alias that has the utility MOVE.COM move it from where it was back to the public directory. No actual copying takes place; only the user number is changed in the directory and the operation takes place extremely quickly. So why wasn't this working with Z80DOS? It took quite a bit of head-scratching to figure this out, especially since my understanding of what was happening with ZRDOS as above only came to me after going through the process of figuring out the error with Z80DOS. I hadn't the slightest idea what 'XXPED.$$$' was. All I knew is that I was always finding a file by this name left on the currently logged user area, and it was exact replica of my original AUXDICT.TXT only with the new learned words added. This was the file that AUXDICT.TXT _should_ now have been. I still hadn't yet pinned down exactly where the error was occurring. All I knew is that ZEX file that my alias invoked was aborting somewhere right in the middle and I was getting a R/O error. So I did what I've taught myself, actually with Ted Silveira's help, to do in these situations: simplify. Take everything line by line, one by one, operation by operation and study exactly what is going on with each. Strip out all unnecessary overhead. I ran the alias several times with printouts in front of me of both the ZEX batch file and the alias and paid careful attention to what was going on on the screen. I realized that it was happening immediately after the disk finished its grinding from having written the new AUXDICT.TXT to disk. I looked and thought, thought and looked, and studied some more, and finally realized: something somewhere is trying to erase AUXDICT.TXT and the operating system isn't letting it. It was then that I pieced together the scheme above of how the new AUXDICT.TXT gets written. It was of course the Z80DOS safety feature: FIXUP.COM was trying to erase AUXDICT.TXT, a public file, and the OS wouldn't let it. But I was still puzzled by this mysterious 'XXPED.$$$'. I assumed it was some sort of temporary file, but where was it coming from? The BDOS? I looked through the code to the Z80DOS source, which is provided along with Z80DOS10.LBR. I found the routines for file deletion and R/O errors, hoping to find that it creates a file named (for some reason) XXPED.$$$ when it is asked to erase a public file and the anti-deletiion safety feature is invoked. I did a string search and found -- nothing. I then hit upon another idea. I loaded up ZPATCH, the ZCPR3 file patcher that makes the CP/M ZAP look like a 1979 version of ED.COM, and took a look at the binary code inside FIXUP.COM. Eureka!! -- there it was: XXPED.$$$. I'm quite certain only God and Correct-It's author know where the name 'XXPED.$$$' is supposed to mean, but it's quite obviously the name FIXUP.COM gives to its temporary file just before it erases the old AUXDICT.TXT. I guess the author couldn't think of a good name for it and gave it the name that he felt was the most XXPEDient... * * * But what is the "code" that I say I cracked? I'm getting to that. So what was I to do now? The BDOS, perhaps quite properly, will not let me erase the old AUXDICT.TXT. How is FIXUP going to work properly? I suppose I could add several new commands to the alias: (1) Log on to the specific user area on which the old AUXDICT.TXT is located (2) Erase it. (3) Make the new XXPED.$$$ a public file. (4) Rename it to AUXDICT.TXT How boring. Enter SETDRU. SETDRU is one of those good old classic CP/M utilities that few people use anymore but were as valuable as a gold mine in their heyday. It does, as a standalone program, what an operating system's public feature does generally. It is used to modify other COM files. A program modified by SETDRU puts a "filter" in high memory which then redirects all the program's internal "calls" made to other, supplemental and subsidiary files it may need for its operation -- overlays, other COM files, text files, etc -- to specific, user-specified user numbers. It is perfect for our purposes. But I had tried and failed, six or nine months ago, to get SETDRU to work properly on Correct-It. I had initially felt that the extra step at the end of the ZRDOS alias that MOVEs AUXDICT.TXT back to the public user area was inelegant and unprofessional. Computers shouldn't have to work like that. In order to get SETDRU to modify a file properly you must provide it the name of each and every subsidiary file to which the main program makes a call, and then specify the user number to which you wish to redirect said call. This is often difficult to do. A call can be either a "read" or a "write", and both must be specified. I remember nine months agao sitting and spending two or three hours with Correct-It, tracing every operation and guessing at when DINDEX.BIN is being invoked, when DICT.BIN is being read, the exact order of invocation, etc. After some time I managed to get the whole shebang working successfully --- until the time that FIXUP should have written the new learned words to AUXDICT.TXT. I just couldn't figure out how to get that right. After prompting me for "Name of auxiliary dictionary to write to? " I would enter 'AUXDICT.TXT' and the operation would abort; it acted as if it were unable to find the file, even though I knew it was there. I knew that some call was being made, but I was damned if I could find out what, who, when, where or how. I gave up. I wrote the simple MOVE command line into the alias and forgot about it. Until last night, nine months later. I figured: it must be XXPED.$$$. That was the secret. It was the missing call. I sat down, found my yellowed, dog-eared notes from my SETDRU experience of those many moons ago, put my programmer's cap back on and loaded up SETDRU one more time. I went through all the same call redirections I found on my paper, but this time additionally redirected FIXUP to XXPED.$$$, and specified the user number. Exited SETDRU, turned off the public file feature on all relevant files, called up my alias, and held my breath. It worked like a charm. CORRECT.COM found FIXUP, FIXUP found DICT.BIN, and FIXUP finally did "find" AUXDICT.TXT. Hard work, study -- and learning from your errors -- does pay off. Thank you, my new friend, XXPED.$$$. * * * Here's how to do it: put CORRECT.COM along your path and put DINDEX.BIN, DICT.BIN, AUXDICT.TXT, and FIXUP.COM all in the same directory. I put mine in user 6. Do NOT make them public files. Then run SETDRU first on CORRECT.COM as follows and exactly in this order: Redirect call to DINDEX .BIN to user 6 Redirect call to DICT .BIN to user 6 Redirect call to AUXDICT.TXT to user 6 Redirect call to FIXUP .COM to user 6 Then run SETDRU on FIXUP.COM as follows: Redirect call to DINDEX .BIN to user 6 Redirect call to AUXDICT.TXT to user 6 Redirect call to XXPED .$$$ to user 6 Redirect call to AUXDICT.TXT to user 6 I've left out several details of the entire alias for which you should consult my CORRECT10.LBR but this takes care of the crucial part. CORRECT-IT can finally be used with any BDOS, with or without a provision for public files, and with or without an otherwise valuable safety feature. It _is_ rather ironic that in this age of modern operating systems with public files and safety features I would rely on for a solution deliberately overriding one of the modern features and utilize instead something from the bad old days of the CP/M yesteryear, but all sorts of things in life are ironic. I thoroughly enjoyed this adventure in debugging. Doing this kind of work gives me a great deal of satisfaction. Happy CORRECT-ing... - Rick Charnes I greatly solicit comments, suggestions and other assorted hoots and catcalls regarding the above flights of fancy. I can be reached at Z-Node Central (Los Altos, CA), Ladera Z-Node (Los Angeles), Newton Centre Z-Node (Boston), Lillipute Z-Node (Chicago), or, God forbid, by voice at (415) 826-9448. --==**==--