Oakland CPM Archive

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

/ Oakland CPM Archive / oakcpm.iso / cpm / zcpr33 / tcj30.mzg / TCJ30.WS

Wrap

Text File | 1988-03-24 | 36.0 KB | 679 lines

After the tremendous effort I put into producing my last column andì ZCPR33 before leaving on summer vacation, I was really burned out. Iì hardly touched the computer or even thought about programming all summer. ì This was quite remarkable, since for months I had practically lived inì front of that computer screen and thought I would have severe withdrawalì symptoms if I didn't get my usual daily fix. I was glad the last issue ofì TCJ came out a bit behind schedule, because three weeks ago I reallyì couldn't think of anything to write about for this column. Then the bug struck again, as I knew it would eventually. My mindì exploded with ideas, and, as in the past, I again have far more things toì talk about than I will have the energy or time to get down on paper beforeì this article has to be sent in. Echelon and I ------------- I practically fainted when I saw the byline on my last column, and Iì wonder if both Echelon and my real employer did too! The byline read:ì "Jay Sage, Echelon, Inc." I guess Art Carlson misinterpreted my statementì that I had joined the Echelon team. In no way am I an employee orì official representative of Echelon. In real life I am still a physicistì at MIT doing research on special analog(!!) devices and circuits for imageì processing and neural-like computing. Digital computing is stillì essentially a hobby. The members of 'The Echelon Team' are independent programmers whoì cooperate with Echelon and each other to advance 8-bit, CP/M-compatibleì computing. Other members of that team, to mention only a few, are Bridgerì Mitchell, author of DateStamper, BackGrounder, and JetFind; Joe Wright,ì author of the auto-install Z-System and the BIOSs of most of the recentì popular 8-bit computers (Ampro, SB-180, On!); and Al Hawley, sysop of Z-Node #2 (the only one to sign up for a node before I did) and author ofì the REVAS disassembler and the new ZAS. Supporting 8-Bit Software Developers ------------------------------------ Though team members have no personal stake in Echelon as employees orì owners, they do benefit to some extent from royalty payments for theirì software that is sold. Nevertheless, before turning to the technicalì material for this issue, I would like to make an unabashed plea to all ofì you to support Echelon and the small number of other companies stillì developing 8-bit software by purchasing their products. They are the onlyì hope for the sustained vitality of our 8-bit world. If we don't buy theì products they offer, the creative programmers who have not already done soì will have no choice but to abandon Z80 programming in favor of the moreì lucrative IBM-compatible market. Check the ads in The Computer Journal,ì and support the companies that advertise there. Do not make regular useì of illegitimate copies of their software; buy your own. Unfortunately, no one is getting rich on 8-bit software. I did notì keep a record of the time I spent on ZCPR33, so I cannot calculateì accurately the effective hourly rate, but a rough estimate indicates thatì babysitting would probably have been a better way to make money. In fact,ì my greatest financial reward probably came from the money not spent onì babysitters as a result of staying home programming instead of going out! While reflecting on these issues, I thought I had a brilliant idea --ì put together a transportable computer and actually hire myself out as aì babysitter. That way I could get paid not only for the commercialì products like ZCPR33 but for all the public-domain programs as well. ì Unfortunately, on more careful consideration, I noted some serious defectsì in this scheme. First of all, how many people would hire me to sit nightì after night until 2 or 4 in the morning? And who would want a babysitterì who wouldn't notice the house burning down until the power went out on hisì computer screen? Basically, I think it is fair to say that all of us (even those, likeì Joe Wright, who depend on it for their livelihood) are in the 8-bitì programming business because we love it. Even for the nonprofessionals,ì like me, there are reasons why some financial compensation is important. ì While we may derive enormous enjoyment and excitement from programming,ì our families do not, but if it brings in a little extra spending moneyì that the entire family can share, they are much more tolerant of the longì hours spent in front of the CRT or on the telephone helping users withì problems. New Commercial Z-System Software -------------------------------- As a transition from my 'soap box' remarks above, I would like toì begin the technical discussion with a review of some exciting developmentsì in commercial Z-System software. WordStar Release 4 The most exciting development in a long time is the appearance fromì MicroPro of WordStar Release 4, CP/M Edition. As far as I can remember,ì this is the first new CP/M product from a major software house since Turboì Pascal version 3 came out several years ago, and it is the only productì ever from a major vendor that supports Z-System. I am thrilled at theì official recognition this bestows on Z-System. For the season's kickoff meeting of the Boston Computer Society'sì CP/M Computers Group, we had representatives from MicroPro to introduceì the new product. As excited as I was about Release 4, I was sure thatì this would be the end of the line, so I was quite surprised when theì representatives talked about a release 5 for CP/M as well as for MS-DOS. MicroPro speaks of itself now as the 'New' MicroPro, and, indeed,ì they sounded like a new MicroPro. They are extremely solicitous of userì suggestions. Their upgrade policy is very generous (they'll happilyì accept the serial number from any older WordStar or NewWord), and theì upgrade price of $89 for individuals and $79 for clubs is very attractive. ì Echelon's special offer at $195 for those who did not own WordStar orì NewWord before is also quite reasonable for such a high quality product. ì I personally have not made much use of WordStar in the past, preferring myì roll-my-own, do-it-my-way PMATE text editor, but I have already placed myì order for WS4, if for no other reason than to show my support to MicroProì and to encourage them to stick with us 8-bitters. Frankly, I am also quite eager to explore WS4's new Z features. ì Since my copy has not arrived yet, I cannot give you a first-hand report,ì but what I have been hearing from others is extremely positive. Itì apparently knows about the command search path and named directories ofì ZCPR3 and can run as a true shell. The documentation included withì WordStar 4 is extraordinary, the equivalent at least of the customizationì package that the 'old' MicroPro used to charge an extra $500 for! Noì longer will the hobbyists have to ferret out all the patch points for theì program (though I am sure there will be plenty of areas, nevertheless, toì keep us entertained). ZAS/ZLINK Another exciting development is release 3 of ZAS/ZLINK, Echelon'sì assembler/linker (and librarian) package. As many of you may know, mostì serious programmers -- Echelon team members included -- have had littleì but scorn for ZAS in the past. It was a strange and unreliable assembler. But Echelon has now really made good on ZAS. They did it right thisì time. They did not go back to the original author and try once again toì get him to fix it; instead they brought in the highly competent Al Hawley. ì Though I am sure it is still not perfect (what program is), it hasì correctly assembled all correct code that I have fed to it. And gone areì its former irritating and unique idiosyncrasies, like square bracketsì instead of parentheses in arithmetic expressions. ZAS will now handleì just about any code written in some semblance of standard assemblyì language. It supports a rich set of pseudo-ops, making it tolerant ofì common variants. ZAS and ZLINK are also at long last honest Z-System tools, as befitsì an Echelon product. They recognize named-directory references for allì files, and they communicate with the Z3 environment and message buffers. ì With an appropriate editor it is possible to build a code developmentì system like that in Turbo Pascal. When ZAS encounters errors in assembly,ì it stores enough information about the first error in the environment thatì an editor can automatically locate the line with the error. Thus one canì make an alias that bounces between the assembler and the editor in veryì convenient fashion. As an added bonus, the Echelon version of ZASì includes, as the one from Mitek always did, the option to generate in-lineì assembly code for Turbo Pascal. If you have an older version of ZAS/ZLINK, you should definitelyì order the upgrade, priced at just $20 for the software alone or $30 withì an updated manual. If for some reason you do not want to do that, youì should at least destroy any copies of the older versions that you haveì lying around. New ZCOM Now I would like to move forward in time and talk about a productì that is in the works (though with the delay between when I write theseì columns and when they reach readers, it may be on sale by the time youì read this). This product is New ZCOM, or NZCOM, Joe Wright's utterlyì spectacular follow-on to ZCOM. This product will make manually installedì Z-Systems obsolete, because manually installed systems will now offer lessì performance than NZCOM systems. First some history. In the summer of 1984 Joe Wright was reflectingì on the difficulty of converting stock CP/M2.2 systems to ZCPR3 andì wondering if an automatic method could not be developed. Rick Connì apparently opined that such a thing would not be possible. Joe did notì ask me (we did not know each other at the time), but if he had, I wouldì have told him the same thing -- impossible! You know the old marines'ì saying: the difficult we do immediately; the impossible takes a littleì longer. Well, Joe didn't even take very long to do the impossible. In aì matter of weeks he had a fully working version. ZCOM had two drawbacks compared to a manually installed Z-System. ì First, it required an extra 0.5K of overhead. Secondly, and ultimatelyì more seriously, it was not flexible. One had to accept a standardì configuration. There was no choice of command processor options, numberì of named directories, size of RCP, and so on. Thus, ZCOM was the Z-Systemì of choice only when a manual system could not be made, either for lack ofì skill or lack of BIOS source code. Since the new computer I bought at work in 1984, a WaveMate Bullet,ì to my chagrin did not come with source for the BIOS, I tried briefly toì figure out how to get ZCPR3 installed without BIOS modifications. I cameì up with an approach that might have worked, but before I got very far withì its development, Echelon announced Z3-DOT-COM and, shortly thereafter,ì ZCOM. I bought them right away. After a short time, I figured out howì they worked (and was amazed at Joe's cleverness). Then I began toì implement the modifications I described in my last two columns, includingì ways to switch between different auto-install systems from within aliasì scripts and while inside shells. Later, after I became acquainted with Joe, I told him about my ideasì for an enhanced ZCOM. It seemed, however, that he was much too busy atì the time with other products to give any attention to ZCOM, so I decidedì that my next project after ZCPR33 would be a program that I tentativelyì called Dyna-Z. This would be a dynamic Z-System, an operating systemì whose configuration could be changed on the fly. Dyna-Z would be useful in several ways. One could normally run aì system with all the standard ZCPR3 modules except an IOP (input/outputì package), giving one a good set of ZCPR3 features for normal operations. ì When one wanted to make use of an IOP, like Joe Wright's superb NuKeyì keyboard redefiner program, a load alias would first check to see if anì IOP space was available in the system. If so, NuKey would be loaded. Ifì not, the alias would switch the operating system to one that did includeì an IOP and then load NuKey. One would sacrifice the 1.5K of TPAì (transient program area -- the memory available for a program to work in)ì only while one needed the benefits of NuKey. On the other hand, when one invoked a command such as WordStar 4 or aì spreadsheet that required a large TPA, an alias for that command wouldì first switch to a Z-System with no IOP or RCP, increasing the TPA by 3.5Kì compared to the full Z-System. One could even drop the FCP (0.5K) and/orì the NDR (0.5K typically). When the memory-hungry program was finishedì running, the remainder of the alias script would reload the standardì version of Z-System. One would hardly know that the operating system hadì been different while WordStar or the spreadsheet was running. Thus Dyna-Z would not only overcome the major disadvantage of ZCOMì but would also overcome the only intrinsic disadvantage of ZCPR3 -- theì loss of TPA space. A minimum Z-System would use only 0.75K plus theì autoinstall overhead (reduced to a mere 0.25K), a very small sacrifice forì all the benefits that Z-System offered. And in a real pinch for TPA, oneì could even drop out of Z-System temporarily and run standard CP/M with itsì maximum possible TPA. Using SUBMIT, even this could be done with aì script! I was delighted this summer when Joe Wright called on the phone toì discuss his plans for New ZCOM. It was the first I knew that he had takenì up the project, and I found that he had already made great progress. Manyì of the features I had planned for Dyna-Z were already implemented, and Joeì was eager to incorporate the rest. Our partnership was born! And it is aì perfect partnership for me -- Joe is doing all the work. I would have been excited enough just to see the Dyna-Z features inì NZCOM, but Joe has done much more than that. He has made the process ofì building a system of your choice about as easy as it could possibly be. ì You simply edit NZBAS.LIB, a text file describing the system configurationì you want, and assemble all the individual components (CCP, DOS, RCP, FCP,ì etc.) to Microsoft-format REL files. NZCOM.COM then generates a systemì auto-loader program for you automatically. It will even allow you toì clone an existing system, accomplishing automatically all the complexì processes I described in my last two columns. JetFind Now I would like to switch back in time and describe a program thatì has been around for a while already but has not had the publicity I thinkì it deserves. It suddenly struck me the other day just how often and inì how many ways I use JetFind yet how few people probably are aware of itsì existence. JetFind, by Bridger Mitchell, is basically a text finding program. ì It is something like Irv Hoff's publicly released FIND.COM, which canì search through a file for a specified text pattern. But it goes orders ofì magnitude beyond that. To begin with, I should explain that JetFind operates in either ofì two modes: interactive or command mode. In interactive mode, the programì is invoked alone, with no command tail. It will then prompt the userì sequentially for each piece of information it needs. The user can thenì live inside JetFind, performing one search after another until he issuesì an exit command. Alternatively, a single search operation can be carriedì out by including all the necessary information on the command line. Now for the capabilities of JetFind. First of all, JetFind is notì limited to searching the text for only a single pattern at a time. It canì search for multiple patterns, and each one can be either a simple textì string or a regular expression (a UNIX concept). Let's take a simple caseì first. Suppose you want to find all lines that contain either "Smith" orì "Jones". In interactive mode you would enter the patterns one at a timeì in response to the prompt. Just hitting carriage return would end patternì input. In command mode, you would enter for the search pattern theì following expression: SMITH|JONES The special character '|' represents 'or'. From command mode, of course,ì one cannot distinguish upper and lower case. To do that you must useì interactive mode. Now let's consider a more complex search that would make use of aì regular expression. Suppose we want to find all labels in an assemblyì language program. We could use the following regular expression: [A-Z][A-Z0-9]*: The first term in brackets means a character from the set of lettersì ranging from 'A' to 'Z'. The second term in brackets is the set includingì the digits from '0' to '9' also, i.e., an alphanumeric character. Theì asterisk means that the previous character specification may occur anyì number of times, including zero times (a '+' would require at least oneì occurrence). Finally the colon on the end represents the ':' character If labels have to be at the left margin, we could use the regularì expression ^[A-Z][A-Z0-9]*: A caret at the beginning of an expression indicates the beginning of aì line. A mode control specification (explained later) can tell JetFindì whether or not to ignore case. If other characters are allowed in labels,ì they could be listed inside the brackets as well. There is not enough space here to give a complete description ofì JetFind's regular expression syntax. Suffice it to say that it canì perform just about any search you would ever want to do. A second major feature of JetFind is that it is not limited toì searching single files; you can specify whole collections of files toì search. You can give a list of ambiguous file specifications both forì files to include in the search and files to exclude from the search. ì These files can all come from a single directory, or files from manyì directories can be included. For example, the file list TEXT:*.D?C ~TEXT:A*.* indicates all files in the named directory TEXT (yes, JetFind is fullyì ZCPR3-compatible) with a file type of D?C but not (that is the meaning ofì the '~' prefix) files whose name begins with 'A'. Note the '?' in theì file type. The intention here is to search all DOC files. By includingì the '?' for the middle letter, files of type DQC (squeezed DOC files) andì DZC (crunched DOC files) will be included as well. JetFind automaticallyì uncompresses both squeezed and crunched files as it searches. Moreover, JetFind is not limited to searching individual files. Itì can even search through members of libraries. If the first file name inì the list of files is an LBR file, then the rest of the list is taken as aì specification of the members of that library to be included in or excludedì from the search. As with individual files, these files can be unsqueezedì or uncrunched on the fly. As if this were not enough, JetFind has about a dozen mode controlì options that define how it performs the search and what it does with theì text identified by the search. Here are descriptions of just a few. C This option just counts and displays the number of matches without showing the matching lines of text. N The lines containing matching text will be numbered in the listing to make it easy to find them with an editor. Rmn This specifies a display region ('m' and 'n' are each digits from 0 to 9). For each line containing a match to one of the patterns, the previous 'm' lines and following 'n' lines will also be included in the display to provide context. I Case will be ignored so that 'a' and 'A' will be considered to match. B Begin displaying the text as soon as the first match has been found. V Reverse the test and display only lines that do not match any of the specified patterns. T Type the file, extracting it from a library and/or uncompressing it as required. With these and other options not listed above, JetFind can be made toì perform many tasks besides searching, such as typing files, extractingì files from libraries, splitting off parts of files, and displaying filesì in a directory or library. We're not finished yet! JetFind also supports full input/outputì redirection. The output text that is shown on the screen can additionallyì be saved to a file, either in a new file or appended to an existing file. ì The set of patterns to search for can also come from a file. Thus weì could have the command JETFIND -WN <ASM:LABEL.EXP ZF*.Z80 >LABELS.LST This would search through all the ZFILER source code (ZF*.Z80) for theì regular expressions contained in the file LABEL.EXP in directory ASM. Theì search would require whole-word matches ('W') and include line numbersì with the matching lines ('N'). The output would be displayed on theì screen and written to a new file called LABELS.LST in the currentì directory. One final comment. JetFind does its work at incredible speed. ì Bridger Mitchell is an absolute master at wringing performance out of theì operating system, using all kinds of tricks to speed up file operations. ì Hence the 'Jet' in the name. JetFind is available from Echelon or Echelonì dealers for just $49. New ZSIG Programs ----------------- Now I would like to turn to some exciting new ZSIG programs that haveì been released or are under development at this time. LLDR -- Library Loader Paul Pomerleau -- already well known to the community as the authorì of such widely used programs as VERROR (visual error handler), BALIAS (anì alias editor), AFIND (alias finder), and the commercial LZED (little Zì editor) -- has released LLDR, a version of LDR with library support. This program completely replaces LDR, the standard module loaderì program used to load new ENV, Z3T, RCP, FCP, NDR, and IOP operating systemì code segments. It does everything LDR did but adds one new, veryì important feature. It can load the modules from a library. ENV and Z3T modules in particular are very short (one or twoì records), and it was very inefficient use of disk and directory space toì have them sitting around as individual files. Now all the system filesì can be collected together in a single LBR file (or several, if youì prefer). LLDR's syntax can be expressed in general form as follows: LLDR [library[.LBR],]<list of modules to load> If the optional library specification is omitted, then it performs justì like LDR. If all the system modules are placed in a file called, forì example, SYS.LBR, then one might invoke LLDR (renamed to LDR) as follows: LDR SYS,SYS.ENV,DIMVIDEO.Z3T,DEBUG.RCP,SYS.FCP,NUKEY.IOP Besides the saving in file space and directory entries, there is anotherì nice side benefit of using LLDR in this way -- it is much faster. Sinceì only one file (SYS.LBR) has to be opened by the operating system, there isì only one directory search, and loading the entire collection of modulesì takes little more time than loading a single one did with the old LDRì program. Thanks, Paul, for another nice program. SALIAS -- Screen Alias Editor When I released VALIAS (visual alias editor) a couple of years ago, Iì wrote in the documentation that someone should please extend it to full-screen operation (it only supported insertion and deletion of completeì lines). Paul Pomerleau's BALIAS allowed full WordStar-like editing ofì alias scripts, but it treated the entire multiple-command script as aì single line. I much preferred the structured presentation of VALIAS, withì each command on its own line. I suggested that VALIAS should be extendedì to automatically indent the lines to show the nesting of flow-controlì commands. It has been a long wait, but finally the wait is over. Rob Friefeld,ì from the Los Angeles area (contact him on Al Hawley's Z-Node #2), hasì released SALIAS (screen alias editor), and what a beauty it is. You willì no longer find VALIAS on any of my disks! With SALIAS, alias scripts are displayed and edited rather as if theyì were WordStar text files. Each individual command is displayed on its ownì line, except that long lines can be continued on the next line by enteringì a line-continuation character (control-p followed by '+') at the beginningì of the continuation line. SALIAS works in two basic modes. One is the command mode, like thatì in VALIAS. In command mode, the status line at the bottom of the screenì displays the following prompt: CMD (Clear Edit Format Indent Load Mode Print Rename Save Undo eXit) Entering 'C' will clear the script editing area. 'E' will enter full-screen editing mode. 'F' will reformat the script, converting it to upperì case and placing each command on its own line, even if the user enteredì lines containing multiple commands separated by semicolons. The 'I'ì command is similar except that it indents the lines by three extra spacesì for each level of IF nesting. Thus a script might appear as follows: IF EQ $1 // OR NU $1 ECHO SYNTAX IS ... ELSE IF NU $2 COMMAND FOR ONE FILE SPEC ELSE COMMAND FOR TWO FILE SPECS FI FI This format makes it very easy to see the relationship between the flowì tests and to detect missing FIs. Entry of complex conditional aliases is greatly facilitated by theì use of the tab key to indent the script as it is entered. The 'I' commandì will reindent the display according to the actual flow levels, even if theì user made a mistake. The spaces (tabs) used to format the display are notì part of the actual alias script. However, leading spaces entered by theì user (to invoke extended command processor operation, for example) will beì included in the script and are displayed in addition to those added by theì indenter. The 'F' command will show the real contents of the script,ì automatically deleting the indentation tabs. The 'L'oad command tells SALIAS to clear any existing script and toì load an alias file for editing. If such an alias already exists, it willì be read in. Otherwise it will be created. 'M' allows one to specifyì either a normal alias or a VALIAS-style recursive alias, one that clearsì the entire multiple command line buffer before it is run. In an earlierì TCJ column I described how one would use this kind of alias for certainì kinds of recursion. The 'P'rint command will send the screen display of the alias scriptì to the printer. 'R' will let one change the name assigned to the scriptì being edited so that a script can be read in from one alias and writtenì out to a new alias. 'S' saves the current script in a file with theì current name. Undo will ignore any editing that has been performed on theì alias and let the user start over with a fresh copy of what was read inì from the file originally. 'X' will terminate operation of SALIAS (withoutì any prompting). SALIAS has an alternative mode of operation entirely from within theì interactive edit mode. All of the functions that can be performed byì commands in command mode, and some others as well, can be performed usingì control-character sequences directly from edit mode. These commands areì as follows. In all cases, the first character (for example, ^K) is aì control character. The second character can be a control character or aì regular character in either upper or lower case. ^KS Save the alias under the current file name. ^KD Done editing -- save the file and then clear the edit buffer. ^KX Exit from SALIAS after saving the file. ^KN Assign a new name to the script. ^KQ Quit without saving the script. ^KR Read in another alias script and append it to the commands currently in the edit buffer. This is very convenient for combining scripts from multiple aliases. ^KF Reformat the alias, listing each command on its own line, removing any flow-control indentation, and converting to upper case. ^KI Indent the alias display to show flow control nesting. ^KU Undo changes that have been made to the script. ^KP Print the script. ^KM Toggle the mode of the alias between normal and recursive. The editing commands follow the familiar WordStar pattern. Even ^QSì (move to beginning of line), ^QD (move to end of line), and ^QY (delete toì end of line) are recognized. The special form ^QZ will zap (clear) theì entire script so you can start over. ^R and ^C move to the first and lastì lines of the script, respectively. ^QF allows searching for strings, andì ^QA allows search-and-replace. ^L will repeat the last search or search-and-replace. ^V toggles between insert and overtype modes. SALIAS is available in two versions. The longer version has imbeddedì help information that can be called up using ^J. In the shorter version,ì the help information has been omitted, and ^J instead is used to toggleì the cursor between the beginning and the end of the current line. I should mention a few other features of SALIAS. There is anì additional status line at the top of the screen. It shows the name andì version number of the program, the type of alias (normal or recursive),ì the number of characters free, and the current name for the alias. The free-character value is calculated by subtracting the number ofì characters presently in the script from the number of characters allowedì in the multiple command line buffer. This computation is not infallible. ì There are some parameter expressions, such as $D, that take up less roomì when expanded, so it is possible that SALIAS will refuse to let you saveì an alias that it thinks it is too long when in fact it is not. Moreì likely, however, is that you will save an alias that has few enoughì characters for SALIAS to accept it but will become too long when theì parameters are expanded. And even if this does not happen, you can runì into trouble when the alias itself appears in a multiple command lineì expression, and not-yet-executed commands have to be appended to the aliasì script. These subtleties aside, having the display of free characters isì helpful. To summarize, in my opinion SALIAS makes all previous alias editorsì obsolete. You should be sure to pick it up from your local neighborhoodì Z-Node. If you do not have one, then join NAOG/ZSIG and order a disk fromì them. VLU -- Visual Library Utility VLU is a utility we have all been wishing for -- a screen-orientedì library management utility. Its author is Michal Carson of Oklahoma City,ì OK. I originally suggested a library shell, like ZFILER but working onì the contents of a library, but Michal pointed out that there is really noì need for the visual library utility to be a shell, since shell functionsì like macros performed on pointed-to files will generally not be applicableì to library members. So he built VLU as a non-shell utility thatì interfaces closely with ZFILER. VLU can be invoked in two ways. Without any file name specified onì the command line, it tries to open a library whose name is the same as theì file name stored in the Z3ENV system file 2. This system file is whereì ZFILER keeps the name of the file it is currently pointing to. If one hasì a ZFILER macro called, for example, 'V' with the simple script 'VLU',ì invoking this macro while pointing to a library (or to another file withì the same name as an LBR file in that directory), the library will beì opened for work by VLU. Alternatively, one can specify the name of theì file on the command line, in which case this name takes precedence overì any name in system file 2. Once VLU is running, the display contains two fields. The upperì field is like that in ZFILER. It displays the names of the files in theì currently logged directory. The lower field is similar in appearance butì shows the names of the member files in an open library file. If noì library file is currently open, this field is blank. As in ZFILER, there is a file pointer that can be moved around usingì standard control characters or, if defined, cursor keys. In VLU, theì escape character toggles the cursor between the upper (file) and lowerì (LBR member) fields of file names. Many operations can be performed on either set of files. Files canì be tagged and untagged, and two wildcard tagging functions are provided. ì 'GT' group tags all files, while 'W' allows a wildcard file specificationì to determine which files get tagged. Individual files or groups of taggedì files can be viewed, crunched (but not squeezed), or uncompressed (eitherì uncrunched or unsqueezed, as appropriate). The 'F' command will show theì size of an individual file or library member at the cursor. For libraryì members, the size is shown in records as well as kilobytes. Additionally,ì tagged individual files can be deleted or renamed, and tagged libraryì members can be extracted, with or without decompression. The special 'GB' or Group-Build function of VLU allows taggedì individual files to be built into a new library. As I write this article,ì the details of this feature have not been fully worked out, but it will beì possible for the user to indicate which of the tagged files should beì crunched according to an automatic algorithm (which will crunch them onlyì if that results in a smaller file) and which should be put into theì library in their existing form. Single individual files will accept the command 'O' to open a libraryì with that name if it exists and the command 'C' to close the currentlyì open library. They can also be renamed using the 'R' command. There are several miscellaneous commands. '/' will toggle between aì built-in help display and the file name display. 'X' is used to exit fromì VLU; 'J' is used to jump to a file; '*' is used to retag files that wereì tagged before some group operation was performed; and 'Q' refreshes theì screen display. Future versions of VLU will include some features not yet in theì present one. A printing capability will be added to complement the 'view'ì functions. Presently, VLU cannot add files to an already existingì library, though it allows the user to specify the number of elements toì accommodate in the library directory so that another tool such as LPUT canì be used to add more files later. VLU has an 'L' command to log into a newì directory. By opening a library in one directory and then changing toì another, one can extract files to a directory other than the oneì containing the library. At present, however, the 'L' command does notì recognize a file mask as ZFILER does to restrict the files included in theì display. Even in its initial release form VLU is a very welcome additionì to the toolbox of Z utilities, and I extend thanks from all of us toì Michal Carson. Subject for Next Time --------------------- As I promised last time, this column has taken a less technical tack,ì though I feel that it has covered important and valuable material. Forì next time, however, I expect to return to a more detailed technicalì discussion. In the past few weeks, I took up the task of rewriting andì expanding ZEX, the ZCPR3 in-memory batch execution utility. This has beenì my first detailed look at a program of this type -- a resident systemì extension (RSX), a program that takes over and replaces functions of theì operating system, in this case the BIOS. I have learned a great deal andì have made what I think are some spectacular improvements to the way ZEXì works and additions to what it can do. Next time I will share with youì what I have been doing and what I have learned.