Fix to Allow DCL to be the Catchall for MCR Mark Hartigan Bankers Trust Company New York, NY 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 installing 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 reered 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 Page 2 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 too 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 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.