At my previous company we used only RSX11M. When we upgraded from V3.2 to V4.0 I decided to set MCR as the primary CLI and install DCL as the catchall task on all of our systems. This proved to be an advantageous configuration for us since it maintained full compatibility with any existing command files designed to use MCR as well as a familiar environment for those of us reared on older RSX systems where MCR was the only show in town. At the same time it allowed people to make occasional forays into the world of DCL without having to change any of the default settings. Without losing the capability to type "PIP /LI" one can type DIR. Without sacrificing the succinct "UFD DL0:[1,54]", one can experiment with "CREATE /DIRECTORY DL0:[1,54]". More importantly, in cases where there are commands which are common to both MCR and DCL (for example RUN), the more familiar MCR form takes precedence. When I first started working with RSX11M-PLUS at my current company, I was very much surprised to find out that this configuration doesn't work. If DCL is installed as the catchall task, it will inform the user that some unnamed task is already active when any DCL command is entered. After several days of disecting the various tasks involved in the command string intrepretation process I found that the problem was actually quite simple to explain and is directly related to the difference in the way RSX11M and RSX11M-PLUS handle commands. Under RSX11M, a command unrecognized by MCR is dispatched to the cathchall task which must be installed as "...CA.". According to the M convention, the first one so activated is called "...CA." and all subsequent ones "CA.Tn". The catchall task (really DCL) then analyzes the command and determines the utility which needs to be spawned. That utility (for example ...PIP in the case of DIRECTORY) is then spawned under its own name (...PIP or PIPTn). It is for this reason that those of us accustomed to using RSX11M, can occasionally be caught typing ABO PIP after having typed the DCL DIRECTORY or TYPE commands. The disadvantage of this system is that a command like PURGE [*,*]*.* (which uses PIP) disallows the use of a command like DIRECTORY (which also uses PIP) from the same terminal since DCL would try to spawn ...PIP twice. Under RSX11M-PLUS, an elegant solution has been found. When the PURGE command is typed, DCL must (as in M) spawn PIP. However, it names the spawned version of PIP "PURTn". A second version of PIP can thus be simultaneously invoked for the DIRECTORY command by naming it "DIRTn". In this way one can have multiple DCL command all using PIP running simultaneously running from a single terminal. This has the additional advantage of allowing the user to abort the DCL command by simply typing ABO PURGE or ABO DIRECTORY without having to know that these commands use a task called PIP. This works when DCL is the primary CLI, but not when DCL is the catchall. The reason for this lies in the fact that this principle of spawning tasks with the name of the command is carried one step to far. When the dispatcher task (MCD.TSK "MCR...") activates the catchall task, it activates it with the name of the command (for example DIRTn). When the catchall tries to then spawn the Fix to Allow DCL to be the Catchall for MCR Page 2 Mark Hartigan Bankers Trust Company New York, NY utility (for example PIP) with the name of the command (DIRTn), the task name is already in use (itself!). The solution requires a change to the MCR dispatcher to name the catchall CA.Tn as in RSX11M. This poses no problem with the concurrent execution of several DCL commands from the same terminal since the catchall task doesn't wait for the spawned utility to exit. After making this change, I unearthed several bugs in DCL which only crop up when DCL is used as a catchall. One involves an incorrect DPB for the RPOI$ directive in the module DCLDAT.MAC which causes the prompt to return before the command execution is complete. The other involves the incorrect checking of a status return in DSPCMD.MAC which makes it impossible to activate the catchall DCL from an indirect command file. Both of these patches are also included and should be made before DCL is used as the catchall. The only remaining bug is that under certain circumstances two MCR prompts are issued after the completion of a catchall processed command. I don't really have any idea why this occurs, but it seems to be relatively harmless so I've left it that way on our systems. Otherwise, we've been using DCL as MCR's catchall now for about three months on all of our V2.1D systems without any difficulties. (Additional notes by B. Z. Lederman) It has been more than three months now, and DCL still works fine as a catch-all. I should note, however, what happened to TDX. Some applications people got used to DLG, and I, for one, like to have CVT around to convert ASCII to Octal, etc. What we did to solve this was quite simple: install one copy of the TDX task image under the different names of the desired commands. For example: INS TDX/TASK=...CVT INS TDX/TASK=...DLG INS TDX/TASK=...DLN and so on for whatever TDX commands you wish to retain. (Don't install it as DIR or TYP, or you will defeat most of the purpose of having DCL as the catch-all.) By having a task installed under a given name, like CVT, and command line which starts with CVT goes to that task rather than being pushed off to the catch-all, and so the proper commands go to TDX. I should also point out that we run on M-Plus with tasks built with external headers, and enough secondary pool so that we can install as many ...XXX tasks as we want without using up any primary pool. The patches mentioned do not have any effect whatsoever on DCL used as a CLI as far as we have seen. We patch the sources, then build two copies of DCL from the same sources: one is built to be used as a CLI, and has MCR catch-all and "." Fix to Allow DCL to be the Catchall for MCR Page 3 Mark Hartigan Bankers Trust Company New York, NY pass-through enabled. The copy built as a catch-all for MCR MUST NOT have MCR catch-all or pass-through enabled, or else you ____ ___ may get an infinite catch-all condition. Using DCL as a catch-all can be habit forming, especially if you get used to some commands like DELete. With PIP /DE, if you forget the version number, you get an error message, but with DELete, it starts listing all of the files by version number and prompts for "Yes, No", etc. Also, as previously noted, since tasks run under their command name, you abort TYPe with ABO ...TYP, abort DIRectory with ABO ...DIR, etc.: no more having to remember that it's really PIP under there. If you use System Accounting, and what to know what's eating up the system, this is very handy as different uses of PIP get listed seperately as DIR, TYP, COP, etc. There is the minor point that if you have DECNet, you won't know if COPy resulted in invoking PIP or NFT, but it does make things a lot easier for the user, who also doesn't have to know when to use PIP and when to use NFT, or even that there is an NFT. There are lots of little places where life is easier with this configuration. I might also mention one other cosmetic change. When you type an unrecognized command, or try to invoke a task which is not installed, MCR returns "Task not installed". If DCL is the catch-all, the same command will result in "Illegal command". It's not serious, but may take a little getting used to for die-hard MCR people. The first SLP file is the change to the dispatcher so that CA. runs as CA.Tn: [12,10]CHAIN.MAC;2/AU=[12,10]CHAIN.MAC;1 -93,94,/;MDH001/ BEQ 8$ ; IF EQUAL YES CMP 2(R3), RCA. ; STARTING CATCH ALL TASK? BNE 10$ ; IF NOT EQUAL NO 8$: MOV 2(R3),(R3) ; SET NAME AT. OR CA. / This change is applied, CHAIN is re-assembled, the new module replaced in [1,24]MCR.OLB, and then re-build MCD. Since MCR... is always active, you will have to remove and install it in VMR, and then re-boot before the change becomes effective. Don't delete the old task images until after you re-boot and the changes are tested. The next SLP file is the change to the RPOI$ directive in DCL. Fix to Allow DCL to be the Catchall for MCR Page 4 Mark Hartigan Bankers Trust Company New York, NY [23,10]DCLDAT.MAC/AU=[23,10]DCLDAT.MAC -2,2,/;MDH001/ .IDENT /MH00/ -220,220,/;MDH001/ $RPOI:: RPOI$ ,,,,,,,,RP.OEX!RP.OAL / The last change is to the status return in DCL. [23,10]DSPCMD.MAC/AU=[23,10]DSPCMD.MAC -2,2,/;MDH001/ .IDENT /MH1.03/ -132,,/;MDH001/ CMPB $DSW, IE.ALG ; This will happen if we're spawned by ICP BEQ SPAWN ; If we were, try $SPAWN / The two DCL changes are applied, the modules re-assembled (look at the command file in [23,24] for the proper method), new objects replaced in the object libraries (DCLDAT goes into [1,24]DCLR.OLB, DSPCMD goes into [1,24]DCLO.OLB, and no, I don't know why there are two libraries just for DCL), and then DCL can be built. Look at the comments in the build file: you will probably want to make a seperate copy with MCR fall-through turned off to build a copy of DCL as the catch-all under a different name (we call it DCLCAT, and of course give it a task name of ...CA.). The catch-all can be removed and re-intstalled while the system is running: so can DCL, provided no one is using it as a CLI while you try to remove it.