CP/M

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

/ CP/M / CPM_CDROM.iso / jsage / znode3 / tcj / tcj41.ws < prev next >

Wrap

Text File | 1994-09-02 | 22.9 KB | 462 lines

The Z-System Corner Jay Sage By the time you read this, summer vacation will probably be just a fondì memory for you, but it is August as I write this, and I have just returnedì from three weeks in Israel. This was a total vacation. I didn't touch orì even think about computers the whole time I was away, except at the very endì when my mind started to refocus on the responsibilities that awaited me atì home, including this TCJ column. It was so nice to get "computerì compulsion" out of my system that I have not been all that eager to get backì immediately to my old routine...but I know it will happen soon enough. Having not thought about computing for a month, I had to work to recallì the things I was excited about before I left and planned to discuss in thisì issue. Fortunately, I left myself some notes. One item was theì continuation of the BYE discussion, this time covering the extended DOSì functions implemented in BYE. The truth is I have neither the energy norì the time to take up that subject now. Instead, I am going to come back onceì again to my favorite subject: aliases and ARUNZ. I think ARUNZ is the one thing that keeps me hooked on Z-System and notì eager to follow after the MS-DOS crowd. Although I have looked hard, I haveì not found anything with the combined simplicity and power of ARUNZ for MS¡ DOS. The mainframe batch processing language REXX, which has been ported byì Mansfield Software to DOS machines, is far more powerful, and some day Iì hope to port a greatly simplified version to Z-System. The DOS version ofì REXX, you see, takes over 200K of memory while it is running! That oftenì does not leave enough memory, even on a 640K machine, for applicationì programs to run. I think I actually have more problems running out of TPAì on my Compaq 386 than I do on my SB180! Anyway, for this column I am going to begin with a very brief report on aì rather dramatic change in the works for ARUNZ and the Z-System as a whole. ì Then I am going to describe two ARUNZ applications that I recently developedì for my own use. I think they illustrate some interesting generalì principles, and you may even find them useful as they are. The Extended Multiple Command Line Most people who use ARUNZ aliases -- or even standard aliases -- soonerì or later run into a situation where the command line overflows and the wholeì process comes to a crashing halt (well, not really a crash, but a suddenì stoppage). The standard Z-System configuration supports a multiple commandì line buffer (MCL) that can accommodate 203 characters. The largest sizeì possible is 255 characters. Either way, there comes a time when aliases areì invoked from command lines that already contain additional commands, and theì combined command line is too long to fit in the MCL. People like Rickì Charnes would have this happen constantly if they did not adopt a strategyì to avoid the problem (more about that in one of our examples later). I have long been intrigued by the possibility of having a much longerì command line. The command processor (CPR) has always used a word-sizeì (16-bit) pointer into the command line, and so, without any change in theì ZCPR34 code, the CPR could handle a command line as big as the address spaceì of the Z80. To verify this, I performed a simple experiment. I configured a Z-Systemì with free memory after the MCL, and then, using the memory utility programì MU3, I manually filled in the command line with a very long multiple commandì line sequence terminated, as required, by a null character (binary zero). ì Sure enough, after exiting from MU3, the huge command line ran without aì hitch. The next step was to write a special new version of ARUNZ that could beì configured to recognize an oversized MCL. Richard Conn set up theì environment descriptor (ENV) with a one-byte value for the length of theì command line that the MCL buffer could contain. Thus there is presently noì way to support an extended MCL (XMCL) in a system-invariant way, that is, inì a way that allows programs to determine at run time how big the MCL is. Weì are working on that problem right now, and, by the time you are readingì this, there will almost certainly be a new ENV type defined (81H) that usesì one of the remaining spare bytes in the type-80H ENV to report the size ofì XMCL to programs smart enough to check for it. The original, single-byte MCL size value in the ENV has to remain as isì and contain a value no larger (by definition) than 255 (0FFH). That valueì is used by the command processor when new user input is being requested. ì There is no way for the CPR to allow users to type in command lines longerì than 255 characters without adding a vast amount of code to perform theì line-input function now so conveniently and efficiently provided by the DOS. ì A shell could be written that included such code, but I really can't imagineì anyone typing in such long command lines. If they do, it probably showsì that they are not making proper use of aliases. I have decided to use only one of the spare ENV bytes for the XMCL sizeì and to let that value represent the size -- in paragraphs -- of the totalì MCL memory buffer allocated, including the five bytes used by the addressì pointer, size bytes, and terminating null. The term 'paragraph' as a unitì of memory is not often used in the Z80 world. I believe it was introducedì with the 8086 processor, where the segment registers represent addressesì that are shifted four bits right. Each unit in the segment register is,ì therefore, 16 bytes and is called a paragraph. With this system, the XMCLì buffer can be as large as 255 * 16 = 4080, which allows command lines withì up to 4075 characters. Rich Charnes, do you think you can live with thatì without cramping your style too much?! Most people will not want to allocate that much memory to the operatingì system, and I would never have considered this step before the new dynamicì versions of Z-System were available. While I might be willing to allocateì 1K to the XMCL most of the time, I certainly would want to be able toì reclaim that memory when I need it. I'm not sure whether NZCOM or Z3PLUSì can be cajoled into handling this kind of flexibility yet; new versions mayì be needed at some time in the future. I put the new version of ARUNZ out for beta test, and it worked justì fine, and one could write very long alias scripts. Rick Charnes, however,ì quickly identified a problem. Suppose a conventional alias appeared in theì command sequence. After expanding itself and constructing the new commandì line, the alias would find that, as far as it knew, there was not enoughì room for it in the MCL. In a nutshell, the hard part with going to the XMCLì is that it is not enough to have an advanced ARUNZ; all programs thatì operate on the MCL must be upgraded. We hope to have new versions of theì library routines in Z3LIB that perform these functions. Then, if we areì lucky, most of the utility programs can be upgraded simply by relinking. ì I'm sure it won't be quite that easy, of course! A MEX Alias For those who are not familiar with it, MEX (Modem EXecutive) is anì advanced telecommunications program written by Ron Fowler of NightOwlì Software. Early versions were released for free to the public (up toì version 1.14), while the most advanced versions (called MEX-Plus) areì commercial products. I use version 1.65, and some of the specifics in myì example apply to that version. I am pretty sure that the technique Iì describe can be applied to the free version as well. Rather than being a telecommunications program, MEX should probably beì considered a telecommunications programming language. It supports a veryì wide range of internal commands for managing telecommunications tasks, andì it even has a script language for automating complex sequences ofì operations. The MEX command line allows multiple commands to be entered just as in Z¡ System, and a MEX command allows the user to define the command separator. ì Although I depend on aliases to generate complex Z-System commands and MEXì script files to automate complex MEX command sequences, I still frequentlyì make use of simple, manually entered multiple commands. Being accustomed as I am to entering Z-System commands separated byì semicolons, I naturally set up my version of MEX to use the semicolon as itsì separator, too. Now I can comfortably work in both environments. However,ì I also frequently like to invoke MEX with some initial commands, which MEXì allows one to include in the command tail. Here's a simple example. B11:TEMP>mex read mnp on This command invokes MEX and tells it to run the script file MNP.MEX withì the parameter "ON". This script causes a string to be sent to my modemì which engages the MNP error correcting mode (yes, when I purchased my mostì recent modem -- replacing a USR Password -- I decided to spend the extraì money for MNP, although at the time there weren't many systems thatì supported it; now I'm glad I did). That command line works fine. But often I want to do more, and so Iì always wanted to enter something like: B11:TEMP>mex read mnp on;call zitel This would start out by doing what the first example did but would thenì continue by placing a call to the ZITEL BBS. [If you can keep a secret,ì I'll tell you that the ZITEL BBS is the MS-DOS system that I run for theì ZI/TEL Group of the Boston Computer Society. ZI/TEL comes from the lettersì in Zilog and Intel, and it symbolizes the fact that we support the two mainì operating systems run on chips from those companies: CP/M and MS-DOS. Theì BBS machine, a Kaypro 286/16, is sitting in the other room (you don't thinkì I'd allow it in the same room with the Z-Node, do you?), and it has an HSTì 9600 bps modem with MNP error correction. If you want to contact me there,ì by the way, the number is 617-965-7046.] An on-the-ball reader already realized that the above command will notì work, because the semicolon separator before the CALL command, which Iì intended as the MEX separator, will be interpreted by the CPR as itsì separator, and it will terminate the MEX command. What can we do aboutì this? Some compromise here is inescapable, and I was willing to accept -- fromì the CPR command line only -- a MEX separator other than semicolon. Thus theì following form would be acceptable B11:TEMP>mex read mnp on!call zitel with an exclamation point as the separator as in CP/M-Plus. But for years Iì could not figure out how to accomplish this. At first I thought there was a very simple solution. When MEX starts up,ì it can be set up to automatically run an initialization script file INI.MEX. ì So, I created a version of MEX (the MEX "CLONE" command makes it easy toì create new versions) that used "!" as the separator, and I created anì INI.MEX file with the command STAT SEP ";" Thus, as soon as MEX was running, the separator would be set back to aì semicolon. Unfortunately, to my chagrin, I learned that MEX invokes theì INI.MEX script only when no commands are included on the command line. Withì the ZITEL command line shown earlier, MEX would be left with the exclamationì point as the separator. Here is what I thought of next (at least momentarily). Rename MEX.COM toì MEX!.COM and set up a MEX alias in ALIAS.CMD with the definition MEX mex:mex! $*!stat sep ";" The idea here is that the user's MEX commands from the command lineì (separated by "!") will be passed in by the $* parameter and will have theì STAT command added. Thus our earlier example will turn into the commandì line B11:TEMP>mex:mex! read mnp on!call zitel!stat sep ";" This, of course, fails for the same reason that I could not just enterì commands with semicolons in the first place. The trick to get around thisì is to use a command that for some reason Ron Fowler does not document in theì MEX manual: POKE. It works like the Z-System command of the same name andì places a byte of data into a specified memory address. I knew the value I wanted to poke: 3BH, the hex value for the semicolonì character. The question was, where should it go? To find out, I took aì version of MEX set up with semicolon as the separator and the version withì exclamation point as the separator and ran the utility DIFF on them (inì verbose mode to show all the differences). Then I looked for the placeì where the former has a semicolon and the latter an exclamation point. Forì MEX-Plus this turned out to be 0D18H so that the MEX poke command would be POKE $0D18 $3B Note that MEX uses a dollar sign to designate hex numbers. The alias nowì read MEX mex:mex! $*!poke $$0d18 $$3b Observe that a double dollar sign is needed to get a single dollar signì character into a command. A lot of people forget this and end up withì scripts that don't do what they're supposed to. I tested this, and it works splendidly -- but with one possible 'gotcha'. ì The commands passed to MEX must not invoke any script files that depend onì the command separator being a semicolon (because it will be exclamationì point until the final poke command runs); nor may the read files change theì command separator (because the rest of the command sequence still assumes itì is the exclamation point). For this reason, it is prudent to write allì script files with only one command per line so that no separator is needed. ì I haven't been doing this, but I will from now on! One final word on the script. I actually did not do this exactly as Iì have described. Instead, I left my MEX.COM set up with the semicolonì separator, and I created a distinct ARUNZ alias called MEX! so that I wouldì be reminded of the separator. This alias script reads MEX! get 100 mex:mex.com;poke d18 "!;go $*!poke $$0d18 $$3b This uses the famous poke&go technique originated by Bruce Morgen. MEX.COMì is loaded into memory by the GET command, and then the Z-System POKE commandì sets "!" as the command separator. Then the modified loaded code is run byì the GO command. The rest is as described previously. A Spell-Check Alias I try to remember to put all my writing through The Word Plus spellingì checker that came with WordStar Release 4 so that as many typos as possibleì will be caught. The procedure for doing that on a Z-System is a bitì complicated because the text file is generally not in the same user area asì the spelling check program. While writing my last TCJ column, I finally gotì fed up with the complexity and automated the whole process using a set ofì aliases. I wanted to support the following syntax: C1:TCJ>spell filename.typ dictname If just the file name was given, the alias would prompt for the name of theì special dictionary to use, and if not even a file name was given, then theì alias would prompt for both names. A special version of the command,ì ZSPELL, would take only the file name and would automatically use ZSYSTEM asì the name of the special dictionary (it knows about mnemonics like ZCPR, MCL,ì and RCP, and about all those special words like debugger, relocatable, andì modem). We'll describe the general alias set first. In listing theì aliases, we will write them in multiline format for easy reading;in theì ALIAS.CMD file the scripts have to be on a single line (though I hope thatì will change soon). The user-interface alias, SPELL, deals only with the matter of how manyì parameters the user has provided. It reads as follows: SPELL if nu $1; /TW0; else; if nu $2; /TW1 $1; else; /TW2 $1 $2; fi; fi If no parameters at all are provided (IF NULL $1), then the secondary scriptì TW0 is run. The leading slash signals ZCPR34 that the command should beì directed immediately to the extended command processor. If a firstì parameter but no second parameter is present (IF NULL $2), then theì secondary script TW1 is run. Finally, if both parameter are provided, thenì script TW2 is run. The script TW1 includes a prompt only for the name of the specialì dictionary file: TW1 $"Name of special dictionary: " /TW2 $1 $'e1 The first token in any user response to the first prompt ($'E1 -- whenì working with ARUNZ you should have a printout of the parameter DOC file) isì used along with the file name that was already given, and both are passed toì TW2. The script TW0 includes prompts for both the file name and the specialì dictionary: TW0 $"Name of file to check: " $"Name of special dictionary: " if ~nu $'e1 /TW2 $'e1 $'e2 fi The first tokens in the responses to the prompts are passed to script TW2. ì If no file is specified for checking, the alias simply terminates. Before we look at TW2, which does the real work, let me ask a rhetoricalì question: why do we break this process up into so many separate aliases. ì There are two main reasons. The first is that the command line buffer would overflow if all these smaller scripts were merged into a single big script. ì The extended MCL we discussed earlier could overcome this problem, but forì another reason we would still have to use separate aliases. As I have discussed in past columns, ARUNZ cannot know at the time itì expands a script what the results of conditional tests will be later whenì the IF commands are run. Thus ARUNZ must process all user input promptsì that appear in the script. This would mean asking for a file name andì special dictionary even when the names were given on the command line. Theì solution to this problem is to put the prompts in separate scripts that getì invoked only when the information requested in those prompts is actuallyì needed. Now let's look at the script TW2. TW2 path /d=tw:; $td1$tu1:; tw:tw $tf1 $tn2.cmp; path /d=; /twend $tn2; $hb: This is simpler than what you expected, no? Well, there is still a lot ofì work imbedded in the subroutine script TWEND, which we will cover later. ì Here we broke up the script solely to prevent MCL overflow. The first command makes use of the ZSDOS file search path (see theì articles by Hal Bower and Cam Cotrill on ZSDOS in TCJ issues 37 and 38). ì Although there was an attempt to update WordStar Release 4 to include someì Z-System support, no such attempt was made with The Word Plus spell checker. ì In general, the file to be spell-checked will be in one directory and Theì Word files in another directory. The main program TW.COM could be locatedì by the command processor using its search path, but TW.COM needs a number ofì auxiliary files, such as the dictionary files. How can the system be madeì to find all of these files at the same time. ZSDOS provides the answer. I have replaced the standard Z-System PATH command with the ZSDOS utilityì ZPATH (renamed to PATH). The first command in TW2 defines the DOS searchì path to include the directory TW:, which is where I keep all the files thatì are part of The Word Plus spell-checking package. Once that directory is onì the DOS path, all files in it will more-or-less appear to be in the currentì directory. Very handy! If you use ZDDOS, the search path is not available. ì I will not show it here, but you can accomplish the same thing using onlyì public files. It's just not quite as neat and straightforward. I amì willing to pay the small memory penalty to get the nice extra features ofì ZSDOS over ZDDOS. The second command logs us into the directory where the file to beì checked resides. If we did not include a DIR: prefix, we were alreadyì there, but the extra command does not hurt, and it is nice to know that aì directory can be specified explicitly (in either DU: or DIR: form) for theì file to be checked. There could be a problem if the file is in a user areaì above 15, since you may not be able to log into that area. My configurationì of Z34 allows this, but when I run BGii I lose this feature (and I sure missì it). If you can't log into those areas, then you should not keep filesì there that you want to spell-check. The third line actually runs the spell checker (you knew that had toì happen some time!). Notice that even if the user specified a file type forì the special dictionary, type CMP is used. Only the name ($TN2) without theì type is taken from the user. As the master program TW.COM is run, it willì find its component program files (e.g., SPELL.COM, LOOKUP.COM, MARKFIX.COM)ì and the various dictionaries in the TW: directory thanks to ZSDOS, and itì will find the text file in the current directory. As it works through theì text, if there are any questionable words, it will write out a fileì ERRWORDS.TXT to the current directory. If any words are added to theì special or UPDATE dictionaries, then the modified dictionaries will be readì from TW: but written out to the current directory. You must understandì these facts in order to understand the rest of the script. Once the spell-checking is complete, the ZSDOS path is set back to nullì (unless I have a special need to have the DOS perform a search, I leave itì this way to avoid surprises). Then the ending script TWEND is run, andì finally the original directory ($HB:) is restored as the current directory. Now let's look at TWEND. As it is invoked, the name of the specialì dictionary is passed to it. TWEND's job is to clean up scratch files and toì take care of any updated dictionaries. It reads TWEND if ex errwords.txt; era errwords.txt; fi; /dupd $1; /dupd updict For efficiency and to prevent MCL overflow, the dictionary updating isì performed by yet another subroutine script, DUPD. It gets called twice,ì once with the special dictionary (if any) and once with the updateì dictionary. It reads as follows: DUPD if ex $tn1.cmp; mcopy tw:=$tn1.cmp /ex; fi If an updated version of the specified dictionary exists in the currentì directory, then it is copied to the TW: directory, overwriting any existingì file of that name (MCOPY option E). The source file is then erased (MCOPYì option X). Oh yes, I almost forgot; the MCOPY here is my renamed version ofì the COPY program supplied with ZSDOS. That is it except for showing you the special ZSPELL version of theì alias. Notice that I make the "ELL" part of the command optional byì inserting the comma in front of that part of the alias name. I also allowì the script to be invoked under the name ZTW. The main SPELL script actuallyì has the name "TW=SP,ELL" on my system. Since TW: is not on my commandì search path, the command "TW" will invoke the ARUNZ script unless I am inì the TW: directory at the time. ZTW=ZSP,ELL if nu $1; /ZTW1; else; /TW2 $1 zsystem.cmp; fi ZTW1 $"Name fo file to check: " if ~nu $'e1 /TW2 $'e1 zsystem.cmp fi I hope you find these alias examples useful and instructive. That's all forì this time. See you again in two months.