CP/M

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

/ CP/M / CPM_CDROM.iso / jsage / znode3 / z3tips / z3tips05.lbr / WS4.NZT / WS4.NOT

Wrap

Text File | 1993-06-08 | 30.9 KB | 539 lines

Z3TIPS05.LBR Bill Tishey 10/24/87 I have compiled this series of notes/tips relating to ZCPR3 primarily from messages between users on Z-Node #3 (617-965-7259) and sysop Jay Sage. Jay graciously provided me his message base for the effort. Messages from other sources may also be included occasionally to expand on certain topics. -------------------------------------------------------------------------- WordStar 4.0 and Z-System 1. Reviews 2. Installation on Sanyo 3. Debugging WordStar 4. WS 4.0 Shelling -------------------------------------------------------------------------- 1. Reviews 09/27/87... I have WordStar 4.0. The verdict: thumbs up! Particular wins, in my view, are the properly functioning paragraph reformatting, embedded rulers, improved WYSIWYG display, and vastly improved installation/ tailoring facilities. No particular problems to far. Haven't given it a real workout yet. It no longer includes SPELSTAR, but then I never had it before, either. It includes instead what I gather is a well-regarded spelling checker package, The Word Plus. I think I like my own spelling checker better, but then I haven't really worked this one yet, either. The 8" distribution (that's what I have - you get your choice, of course) comes with SIX SSSD disks. I can get the whole thing on one of my DSDD disks, so i guess it comes to about 750k or so. The dictionary alone is something like 120k, and there are some neat utilities that come with it. The documentation is complete, and has a full index. Being very familiar with WordStar 3.0, I've hardly looked at it. It's not like either the 3.0 or 3.3 stuff. It does contain both tutorial and reference. Yes, it's worth the money. (Ken Wallewein) 10/15/87... My first impressions of WS 4.0 were mixed -- the editor had more nice features; but, the printer drivers didn't! WS4 refused to default to ".LQ OFF" and printer redirection appeared to be a 128 byte patch area with scanty documentation. I got a call from MicroPro a couple of days ago to inform me that WSCHANGE had a "bug" in it and that the ".LQ" and ".BP" flags had switched places. A little further checking showed me that WSCHANGE program and the PATCH.LST file both agreed but WS4 was looking in the wrong place! (Or maybe WS4 knew what it was looking for, but nobody else did) Anyhow; in the WS.COM file the ".LQ" toggle really lives at 0812H and ".BP" at 0813H (switch those addresses in your PATCH.LST file). And, when using WSCHANGE, ".BP" is really ".LQ" and vice versa. I still haven't figured out why the auto page numbers at the bottom of the page sometimes are it the opposite .LQ mode than the body of the text! My second problem was that I have an Olivetti PRAXIS serial input typewriter that I use as my daisy wheel printer. I am using an MSC-ICO C/PM+ computer board, and with WS 3.3 I would exit WS and use DEVICE to redirect the LST: output to a serial port and then go back into WS and print. WS4 suggested that printer output redirection could be done from within WS4. For my C/PM+, at least, that means here's a 128 byte patch area -- go for it! So I did. I spent an hour or so using SID to find the SCB byte in high memory that redirected the LST: output and the values for the devices my system supports. Following is my assembly language solution: ;-------------------------------------------------------------------------- ;ULPORT.MAC .Z80 ;"ULPORT" SUBROUTINE COMPARES WS4 PRINTER DRIVER TO "PRAXIS,0" DRIVER NAME, ;IF A MATCH IS FOUND THEN LOAD "RS2" (08H) USING "OUTRS2" TO SCB AND RETURN, ;ELSE THEN LOAD "CEN" (40H) USING "OUTCEN" TO SCB AND RETURN, ;IF "PRAXIS" IS USED TO PRINT THEN USE "RETCEN" TO LOAD "CEN" TO ;REINITIALIZE SYSTEM "LST:" OUTPUT ; ;THIS OUTPUT REDIRECTION IS FOR USE ON AN MSC-ICO Z-80 COMPUTER BOARD ;FOR WHICH THE SECOND SERIAL PORT (RS2) HAS BEEN INITIALIZED TO 300 BAUD, ;8 BIT WORD, 2 BIT STOP AND NO PARITY FOR MY OLIVETTI PRAXIX P-41 TYPEWRITER ;BY REWRITING "CPM3.SYS" (CPM3.SYS HAS ALSO BEEN CHANGED TO DEFAULT TO ;1200 BAUD FOR THE FIRST SERIAL PORT -- SO THERE IS NO NEED TO RUN "DEVICE" ;IN "PROFILE.SUB" TO SET UP THE SYSTEM) SCBLST EQU 0F5C7H ;SYSTEM CONTROL BLOCK LST: REDIRECTION VECTOR ADDRESS ;THIS JRDII'S CP/M+ --- SO DON'T HOLD YOUR BREATH!! CEN EQU 40H ;LST: VALUE FOR SCB CENTRONICS REDIRECTION RS2 EQU 08H ;LST: VALUE FOR SCB 2ND SERIAL PORT REDIRECTION ASEG ;ABSOLUTE TO GET THE ADDRESSES ULPORT: ORG 063BH ;WS4 "PRNPAT" BEGINNING ULPORT:: CALLS THIS PUSH AF PUSH BC PUSH DE START: LD DE,DRIVER NEXT: LD A,(DE) CP (HL) JR NZ,OUTCEN CP 0 JR Z,OUTRS2 INC DE INC HL JR NEXT OUTRS2: LD A,RS2 LD (SCBLST),A POP DE POP BC POP AF RET RETCEN: PUSH AF ;ULUNPT:: CALLS THIS PUSH BC PUSH DE OUTCEN: LD A,CEN LD (SCBLST),A POP DE POP BC POP AF RET DRIVER: DEFM 'PRAXIS',00 END ;-------------------------------------------------------------------------- The ULPORT:: patch address should "CALL 06B3H" (PRNPAT::) and ULUNPT:: should "CALL" the address that RETCEN: assembles to on your system. I have learned to routinely use many of the "new" features, although I have not had a chance to use them all, and have usually been sucessful. Print time formatting (.PF) looks like it could be a super tool. My wife writes a lot of documents that will be printed single spaced, but she likes to proof then on a double spaced draft print. Simple, just put ".PF" and ".LS 2" at the top of the document before it is printed (comment out the ".LS 2" while editing). This idea sort of works, the document prints double spaced; BUT, WS4 will not recognize the ".LM x" commands she has put in the text to indent paragraphs and phrases. WS4 blithly prints using the page setup defaults and everything comes out printed flush left -- I don't know whether the problem is mine or WORDSTAR's! The new dictionary supplied with THE WORD PLUS is larger; however, its vocabulary for "real writers" has diminished while its knowledge of words used by "computer review writers" has been enhanced. No thanks, I'll stick to my old KAYPRO version! Except for the few problems that I have run into, I've been pretty happy with WS4. Some of the features that are on the IBM-PC version (such as selective page printing) would be nice, but probably make it even more of a memory hog and slower yet. There are still some serious "bugs" to be worked out yet, and I hope the solutions will be coming from MicroPro. 2. Installation on Sanyo 07/26/87... I have started using a Z-Com system w/utilities on my Sanyo 1200, and can get all my old CPM stuff to run except Wordstar. This is not the usual problem with WS.OVL, but a new bug. When I boot the pgm., all it does is log the disk and freeze the keyboard. The initial logo does not even come up. The copy I use came bundled and installed for the Sanyo (install.com will not install any other terminal). I think it is looking for a specific RAM pattern that it cannot find w/the Z-Sys. Does anyone know of a patch, address, hammer, or etc. that I could use to fix this? (Yes, it will run on my CPM, even out of FRONT51). (Charles Dupree) 07/27/87... The version of WS that comes with Kaypros has an added bit of code in the patch area that runs on startup and exit. What it does is modify the system so that the Kaypro cursor keys are translated into the WS values. (^S ^E ^D ^X.) Once this was removed, the program ran fine on a 'normal' CPM machine. If you have a list of the patch points for your version of WS, take a look in that area and see if something similar has been added. Part of the problem was the patch used Z80 code which hung the machine, and part was that it was poking values into the OS which only made sense with the Kaypro. Hope this is of some help. (larry Schnitger) 3. Debugging WordStar 08/02/87... The beginning of your test procedure was fine, but don't use the 'G' command. That just starts the program running full speed. You have to use the trace commands to follow program execution one step at a time. As I said before, be suspicious of any command that gets the address at location 0001 and tries to use it to compute an offset address. A typical sequence would be: LHLD 0001 ; Get address of BIOS warmboot entry point LXI D,nn ; Offset to stuff we want to access DAD D ; Add the offset so HL points to it If you had a debugging tool like DSD, you could set complex breakpoints that would stop the code automatically on a reference to address 0001. If you still are not making progress, you could upload your WS.COM to the private area here, and I could take a quick shot at locating the problem (though I cannot promise to spend too much time at it). (Jay Sage) 4. WS 4.0 and ZFiler 09/29/87... I am having trouble getting WordStar 4 and Zfiler to work properly together. The macro command for going into WS, into Document mode, and then opening a file, which worked fine with WS33, no longer works properly. (I am running Z33 with WS4 installed to work as a shell. The version of ZF that I am using is an earlier one--10B, I think. Would that make a difference, perhaps?) What happens, when I give the macro command with the pointer at the desired file, is that WS is loaded, but instead of going into D mode and opening the file, WS gives me a warm boot and the "strike any key to return to Word-Star" message as if I had just "run" a program from the WS shell. When I exit WS, I am returned to the ZF shell properly. If, instead of using the macro, I give the command manually, using the Z command, it works properly (going into WS, editing, and then coming back to ZF). It looks like the command isn't getting through via the macro. I am using the same script that worked on WS33, copied from one of yours, but very straightforward (no IFs and so on). What am I doing wrong this time? (Alan Campbell) 09/29/87... The problem you report is very interesting. What I suspect is happening is that when command lines are put into the command buffer by a ZFILER macro, the shell running message flag is still set. Since WS now knows about shells, it tests that flag and decides (properly based on the info it receives) that it has been invoked not as a user program but as a shell. You might want to try a recent version of ZFILER to see if I did catch and fix such a problem (though I have no such recollection). If it does persist, I will have to put it on my list of things to fix. When I get a chance, I will try invoking some other shell, like another copy of ZFILER or VMENU from a macro command line and see if it also thinks it has been called up as a shell. Thanks for the report. (Jay Sage) 09/29/87... I just tried to reproduce the problem using ZFILER 1.0H by invoking MENU and FM from macro commands, and I had no trouble. My copy of WS4 has still not arrived, so I cannot try the exact situation you reported on. Maybe things will work with the new ZFILER. Otherwise, there is a slight chance that there is a problem with WS4 (I would prefer that the problem be with ZFILER, since that I can fix!). (Jay Sage) 09/30/87... Changing to ZF10H didn't make any difference, but in the course of experimenting with it, I found out what was going wrong, I think. The script I was using was: $d$u:;ws $f;$h: I may be remembering it wrong, but at any rate it was one that had worked before, as I said. Now it will work only if the final ";$h" is removed. WS 4 will now accept options on the command line ("p" for print directly, "n" for nondocument mode). This is mentioned in the advance PR material, but I haven't been able to find it in the documentation. Nevertheless, it is in effect. Apparently what is happening is that that final parameter is being expanded and then passed on to WS as "B0:". The same undesirable results can be reproduced by entering the whole thing in expanded form on the command line. It seems that WS is being passed the expanded parameter, taking it for an option, gagging on it, and then offering to "return" to its opening menu. (I wonder if this would affect other programs that expect options on the command line?) Removing that last parameter proved to be necessary in the one for the "Z" macro, also, to get it to work correctly with WS4. Actually I have never quite understood the necessity of that last "$h: since you are returned to ZF whether it is there or not. Sorry to have put you to the trouble of checking this out. I should have experimented more myself before calling for help. Maybe no changes will be necessary? (Alan Campbell) 09/30/87... Now it sounds as though it may be a WordStar problem. Once there is a semicolon in the command line, WordStar should stop reading (actually, the command processor only parses up to the semicolon, so programs that use the command tail in the buffer at 80H do not know about the rest of the command line. Something sounds fishy about the way WordStar is running under ZCPR3. I will now be even more eager to get my copy and look into this situation further. (Jay Sage) 10/01/87... While taking a shower a few minutes ago (isn't that one of the best places to think), I hit on the explanation of the problem you described. WS4 is, unfortunately, acting like a TRUE shell (not the way I would have written it). When WS begins running, it installs itself on the shell stack and checks to see if any commands are pending in the command-line buffer. If so, it executes them and only then begins its own execution. So, whenever there is any other command after the WS command in the command line, you will enter WS from a shell with the strike-any-key message. This is not how I would have written this. One does not really want WS to take over the command processor function. It is primarily an editor. I think one of the following two approaches would have been superior. First, WS could have installed itself as a shell only when the 'R' command was used. Then it would have behaved correctly for normal operations. However, once the 'R' command was used, not only would the user's new command be executed; any pending commands after WS would also be run. This would not be desirable. The best approach would have been for WS to use the old ZCPR2-style approximation to a shell. When the 'R' command was used, the command line entered by the user would have the WS command appended to it followed by any other pending commands in the command line buffer. The result would be placed into the command line buffer for execution. In this way, pending commands would not be executed until the user exited from WS. The way things are now, you cannot put WS in an edit/ assemble/link alias, since the assembly and linkage will be performed before the editing!!! This is quite unfortunate. By the way, the reason for the $H: at the end of the ZFILER macro is to maintain the user's default directory, i.e., to undo the effect of the directory change $D$U:. This may no longer be necessary, since, I believe, I have made ZFILER keep track of its home directory on the shell stack so that it will always return there no matter how many times a macro or 'Z' command has changed it. A second comment. If WS recognizes the DU form, try the macro "WS $P" instead of logging into the directory. Let me know if that works. And thanks for all of your comments. (Jay Sage) 10/01/87... So THAT is what was causing it! Not very good news, for as you say if no additional commands can safely be put after "ws fn," it won't be possible to use complicated aliases. For simple "edit this file" type of commands, of course, leaving off any additional commands is a kind of solution. Would it be possible to get around this by using interactive commands via ZEX? Or would subsequent commands cause trouble even there? Or could something be done with GET and GO? You wondered whether WS4 recognizes DU commands. Yes it does--even under straight CP/M, apparently. And that raises the possibility of another solution, albeit a somewhat dirty one. I tried WS4 under ZCPR3.0, without running Z-RIP on it, and the problem we have been talking about did not occur (I will have to recheck this). Perhaps it could be used under Z33 without telling it about ZCPR during the installation process (or perhaps it could be patched so that Z33 does not autoinstall it?). Not running WS4 as a ZCPR33 shell would be a kind of solution, though it would defeat the purpose that a lot of people have been talking about. I wonder what would be lost, actually? The only things the user is made aware of are named directories. These show up in the directory listing on the opening menu, but they are not shown on the status line during editing. Of course DIRs are recognized by WS4 in commands, and that would be lost, too. I suppose there are other, transparent things that would be lost, but the DU feature would still be there. Would recognition of the path in R commands to run other programs be lost, too, or is that controlled by ZCPR? That could be a serious loss! I look forward to hearing what you come up with after you get your copy! In the meantime, I will try the command "ws $p," and let you know what happens. (Alan Campbell) 10/01/87... My copy of WS4 was waiting for me when I got back from work today. Unfortunately, I am going to be extremely busy for the next couple of weeks and will probably not have a chance to look at it. It sounds as though a little work with a disassembler and patcher are going to be in order. And a letter to MicroPro so release 5 will be better. Perhaps if I had been involved in the testing before release I would have caught this. Of course, Echelon and MicroPro wrote it exactly as a shell should be. Trouble is, WordStar should not be a shell! It should be a self-chaining program. I am sure that with a debugger one can easily defeat the shelling. Provided one can enter multiple command lines from the 'R' command, one can simply append a ";WS etc" to each command if one really wants to return to WS. (Jay Sage) 10/02/87... Thanks for your messages. I did try WS $P, as you suggested, but the results were the same. I also tried to fool WS by using an embedded Alias, but of course WS gobbled up the remainder of the main alias and ran any following commands. (I admit I should have expected this after reading your explanation, but it is fun to experiment.) You can indeed RUN multiple commands from within WS. You can also run RCP commands (the manual gives the impression that you can't). It will be interesting to see what you come up with when you get around to trying the patch you mentioned. I myself am going to try to get this out of my mind and go on to a more exciting project (the system reconfiguration you discussed in the last issue of TCJ). (Alan Campbell) 10/06/87... (Raising hand as person responsible for WS4's shell behavior) There are three alternatives for folks who are inconvenienced by WS4's shell capabilities. The first is: use it! The combination of the <esc> macros in WS4 plus an R command that can do anything allows you to do many of the things now being done by MENU, etc. Another alternative is to deliberately load up your shell stack so it is full when WS is invoked. If WS sees the shell stack is full, it will not behave as a shell, since it can't install itsef as one. This is easy to do with multiple invocations of HSH or z/vfiler, and retains the other ZCPR3 features of named directories and path search for overlays. The most drastic step is to patch WS.COM so it will no longer be recognized as a ZCPR3 utility and not auto-installed by ZCPR 3.3 or Z3INS. It won't behave as a shell at all if you do this, but you'll also lose the other ZCPR3 features. (Dave McCord) 10/15/87... Hi, I noticed your messages a few weeks ago about having problems with WS4's shell capability. Just wanted to second the motion. I am _extremely_ disturbed that WS4 has come out this way; it is most unfortunate. I have a very important WS application which I would use daily in which I would like to run WS4 from an alias. Just can't be done. Neither of the three suggested alternatives really make any sense for us. One of the things I always did with NewWord is set up a 'shell loop' between running it and patching it with its 'install' program, NWINSTAL (comparable to WINSTALL): SHSET NWINSTAL NW;NW;CMD Now this won't work with WS4 either. It's really too bad that WS4 was created this way. It seems that the disadvantages easily outweigh the advantages. (Rick Charnes) 10/16/87... Yes, I think a lot of other people are going to be very displeased once all the implications become clear. I am not a programmer, myself, but my little bit of experience with assembling Z-System files has shown me what a convenience an "edit--assemble--link" alias can be. My own uses would be limited to something really simple like edit--spellcheck--print. WS4's print-and-exit command line option would make that easy were it not for its behavior as a shell. Perhaps someone will come up with a patch that will make WS4 behave as described by Jay (not a shell but a self-chaining program) in a way that will let us have the advantantages of ZCPR interaction without the disadvantages? I hope so. In the meantime, the last of the three suggested ways of using the program seems to me to be the only viable one. I don't see how WS4's macro feature combined with its ability to RUN programs can give anything like the power and flexibility of aliases. If it can, I would like to see it demonstrated. As for the second suggestion, how would that work? If the shell stack is full, would WS cease to function as a shell but still have all the other ZCPR features, as suggested? That would be nice, but would you have to fill the shell stack every time you loaded WS? Would other shells such as ZFILER or MENU still work? Could you make stack-stuffing part of an alias? I am afraid that this is a bit over my head. The third method would be like going back to WS33 or new word, but with a few new features. Recognition of DUs would still be there. WS doesn't do much with named directories, and for people like me with small systems, DUs alone are ok, I suppose. The real loss would probably be path-search for overlays, and doesn't Public ZRDOS take care of that? (With only two floppies, these considerations don't mean too much to me, but I can see that they would to most others.) Hope we don't have to wait for version 5 for a solution to this mess. (Alan Campbell) 10/17/87... I have been hunting around in the WS.OVR file for the code that handles the shell stack and command line buffer. I think I have located the code but have not had the time to completely decipher what is going on. In the process of doing this, I thought of a simple, though imperfect, solution to the problem. First I wrote a patch to do this using the INISUB and UNISUB routines in WS4, but then I decided it was better to handle it with alias scripts. The basic idea is to turn off the shell stack while WS4 is running by setting the number of stack entries in the ENV descriptor to 0 temporarily. Make the following ARUNZ alias: WS0 POKE (ENV+20H) 0;WS $*;POKE (ENV+20H) 4 Replace the expression (ENV+20H) with the address of the environment descriptor in your system plus 20H. When you want to run WS with shelling shut off (such as in a multiple-command alias script), just refer to WS0 instead. For normal operations you can still use WS and get the full capabilities, such as the ability to pass multiple command lines to WS4. This is lost when the shell stack is disabled. I will try to figure out a way to really fix the problem some time. (Jay Sage) 10/17/87... With the shell stack disabled, the 'R' command works fine for me so long as I select a command that can be loaded by WS to 100H and run. If you specify a type-3 COM file, there will be a disaster (that is another reason for adding the protection of TYPE3HDR.Z80 to those programs). I would strongly recommend my solution of setting the number of shell entries to 0. That does not interfere with any shells currently running and works whether or not a shell is in effect at the time the alias is invoked. It seems to me that your alias will not work if no shell is loaded at the time it is invoked. I will take another look at the WS code and see if I can figure out how to turn off shells in the code and change the 'R' command to jam the new user command, along with ';WS' in front of any existing commands in the multiple command line buffer. It may be hard to find the room to do this, and it is not easy work to deal with code stashed into overlays (and with no source code). Hawley's REVAS3 may do the trick, however. (Jay Sage) 10/17/87... I'm about to upload a prepared message that solves the problem in exactly the same way Jay's message just now does. Yeah, the idea is basically "stack-stuffing" as you suggest in your message. I think Dave's suggestion that the combination of the WS4 <ESC> macros with the "R" command gives it something like the power of MENU.COM is a bit optimistic, since it has no provision for automatically including a standard filename in any 'macro command line', such as MENU.COM does with system files. Though you know the more I think about it, it sounds like it might be fun to play with. Just use that <ESC> macro screen as your 'menu screen'. I'll play with it. I think having two versions - one shelling and one without (having filled the shell stack with an alias) -- might be a good way to go. Yes, with the stack-stuffing solution you _do_ still have the other ZCPR features such as NDR's and pathing. (Rick Charnes) 10/17/87... After being upset for a while about the difficulties in running WS4 from inside a ZCPR3 multiple command line and feeling dissatisfied with the solutions heretofore proferred, I came upon a solution that I feel works quite well. Dave McCord noted that if WS4 finds the shell stack full at the time it is invoked it will not behave as a shell. As far as I'm concerned this is precisely what I want. He suggested deliberate multiple invocations of HSH, Z/FILER, etc. to overload the shell stack. This takes too much time and is both awkward and inelegant. Here's a better solution, as in this alias WSTEST: WSTEST poke fe20 01 80;echo loading wordstar;ws $*; << echo exiting wordstar;poke fe20 04 20 In the standard Echelon Z packages FE20h and FE21h are the two bytes in the system environment that hold respectively the number of elements in the shell stack and the number of bytes per stack. So, assuming HSH or other history shell remaining loaded in the background (1 shell element) we temporarily turn our system into one with only one element 128 bytes in length, (01 80). WordStar then loads fine -- AS A NON-SHELL -- and then upon exit we return to our standard 4 elements of 32 bytes each (04 20). Normally when you have a shell anywhere in an alias it will insist on executing all commands in the alias -- EVEN THOSE OCCURRING AFTER IT ON THE COMMAND LINE -- before it will itself run. Without the above POKEing we would see the "EXITING WORDSTAR..." message before WordStar loads! However, once we've POKEd FE20 01 80 WordStar no longer behaves as a shell and will load itself assertively in the command line. The "R" command, however, will not work and seems to lock up my system. Note, by the way, that we are only able to do this because WordStar *is able to* run as a non-shell as of course it does under a straight CP/M system. If, however, you try substiting ZFILER or VMENU or other shell in the above alias you will be politely presented with a "SHELL STACK FULL" error message and exit. (Rick Charnes) 10/18/87... Thanks for your suggestion that setting SHSTKS in the environment module to 0 will not interfere with any shells previously running. I'll try your alias. (Rick Charnes) 10/21/87... Peter Mireau from MicroPro, the major author of WS4, spoke to our combined BAMDUA/BAKUP (Morrow/Kaypro) meeting last night. I asked him about the problem with WS4 spitting out a string of U's when it exits. He said he didn't know what the problem could be and had never heard it before. He said that his first thought, though, was that it was a problem of WS4 not 'de-shelling' correctly ---- and that is precisely my instinct as well. I don't know what more to say other than that I feel WS4's shelling could have been handled better. MicroPro pretty much relied on Echelon to handle that side of the matter. (Rick Charnes) 10/22/87... Only the very first byte of the shell stack space has to have a 00 to clear the stack. The U's are probably the result, as you say, of the way your machine is initializing memory. It should cause no problem. Should! Unfortunately, there do seem to be some further insidious errors in the shell coding in WS4, and I have had the experience of WS sending my machine into endless loops of garbage commands. Once a shell stack gets filled with something that one cannot stop and get a 'command in edge wise' as it were, only the red button will stop things. I have tried to decipher the code in WS.OVR, but that is a very difficult job, and I have the feeling my time is better spent on other tasks. It really is a shame the Z coding was so badly botched. I hope Dave McCord will have some feeling of remorse and (since he presumably has the source) that he will figure out and release a patch to eliminate all use of the shell stack and do everything with command chaining. (Jay Sage) --------------------------------------------------------------------------