Designing Useful Utilities as Indirect Command Procedures James I. Shultz USDA, Nutrient Composition Lab Beltsville, Md Introduction ____________ The Indirect Command Processor (ICP) can provide a very convenient way to develop useful utilities in RSX. Even some privileged tasks can be simulated by indirect command procedures, often with little effort on the part of the programmer. With the introduction of named directories and encrypted passwords in RSX-11M-PLUS V3.0, several privileged tasks available from DECUS SIG tapes or the DECUS library would not work properly. Two of these most useful privileged tasks, UIC (K. Cross, 1980) and WHO (G. Maxwell, 1980), are good examples of utilities which can be simulated in ICP. For those who are unfamiliar with these two tasks, UIC provided a way for a user to set his/her default directory by entering a last name as an argument. The account file would be scanned and the default device and directory for this last name would be set as the current directory for the user. If the particular last name had several account entries, the user could also specify the password associated with that last name to have the default directory set to the default device and directory for that account. The WHO task provided the user with an informative display of which terminals were logged on, the name of the person logged on that terminal, the current uic, the tasks active on that terminal and the status of each task. WHO could also take as an argument a uic or last name and after scanning the account file, report the name and default device and directory for that argument. Because these tasks were used very frequently at our installation, they "broke" under v3.0, and they were easy to simulate with an indirect command procedure, I will use these as examples. Customizing TDX -- (getting around the @) _________________________________________ TDX is a catchall task which will accept commands unrecognized by DCL or MCR. To mimic invoking a task installed as ...xxx, TDX must run the argument passed to it as a command procedure (i.e. @UIC), rather than attempting a flying install. Defining a global logical, ZZ2:, will cause TDX to invoke commands sent to it as indirect command procedures. Also, by customizing TDX, it can look for the command procedure in various directories and in a certain order. This allows having certain procedures available only to select users and other procedures available for everyone. At our site, we have DCL, MCR, and TDX set up as shown on the next page. Utilities in ICP Page 2 ---------------- yes Command xxx ---> | Valid DCL? |------> xxx ---------------- | no ---------------- yes | Valid MCR? |------> xxx ---------------- | no --------------------------------------------------- | T D X | | | | 1) Internal TDX command? | | 2) @SYS$LOGIN:xxx.CMD? | | 3) @LB:[2,5]:xxx.CMD? | | 4) @SYS$LOGIN:CATCHALL.CMD -- xxx is argument | | 5) @LB:[3,54]:CATCHALL.CMD -- xxx is argument | | | --------------------------------------------------- When a user enters a command which is not a valid DCL or MCR command, TDX first checks to see if it is a valid TDX internal command. If it is not, TDX checks to see if a command procedure by that name exists in the user's login directory. If it exists, it is run. Otherwise, TDX then looks for a command procedure by that name in a pre-determined directory - (for our installation, LB:[2,5]). If it exists in LB:[2,5], it is run. Otherwise, the command is passed as an argument to a command procedure in the user's login directory named CATCHALL.CMD. If CATCHALL.CMD does not exist in that directory, the command is finally passed to LB:[3,54]CATCHALL.CMD. On our system, LB:[3,54]CATCHALL.CMD, issues a RUN with the command as its argument. As an example, if the user enters: XYZ, since this is an invalid DCL and MCR command, TDX tries the following in order: Internal TDX command "XYZ" SYS$LOGIN:XYZ.CMD LB:[2,5]XYZ.CMD @SYS$LOGIN:CATCHALL XYZ @LB:[3,54]CATCHALL XYZ The final disposition of XYZ will be done in [3,54]CATCHALL.CMD as: RUN $XYZ/task=xyz/com:"" If XYZ.TSK does not exist in [1,54] or [3,54], then you get the familiar: INS -- File not found Utilities in ICP Page 3 With the CLI's and TDX set up as above, we now have a situation where a user can invoke a command procedure in exactly the same way as a task installed as ...xxx. There is also the additional advantage of having TDX search through the user's login directory first before going to the command procedure default directory, LB:[2,5]. Requirements for the procedures _______________________________ Given that ICP has very limited access to system data structures, certain workarounds must be implemented. Using UIC and WHO as examples, rather than attempting to look at the system account file, these two utilities when written as command procedures depend on another command procedure (LB:[1,2]SYSLOGICS.CMD) which is run as part of the system startup procedure. SYSLOGICS.CMD is a procedure which makes a global logical assignment for every user on the system. For example for a user named SMITH, one could assign the following logicals using the MCR ASN command in the SYSLOGICS command procedure: SMITH$ ======> DR0:[SMITH] - Smith's login directory SMITH$DOC$ ======> DR0:[SMIDOC] - Smith's manuscripts SMITH$PGM$ ======> DR0:[SMIPGM] - Smith's programs (etc.) This setup allows SMITH to be associated with several directories. To simulate the UIC task, the UIC command procedure accepts as an argument a character string in any of the following forms: Argument Result -------- ------ SHOW DEFAULT DU: SET DEFAULT DU: DU:SMITH SET DEFAULT DU:[SMITH] DU:[SMITH] SET DEFAULT DU:[SMITH] DU:1,54 SET DEFAULT DU:[1,54] DU:[1,54] SET DEFAULT DU:[1,54] DU:001054 SET DEFAULT DU:[001054] DU:[001054] SET DEFAULT DU:[001054] 1,54 SET DEFAULT [1,54] [1,54] SET DEFAULT [1,54] 001054 SET DEFAULT [001054] [001054] SET DEFAULT [001054] SMITH If [SMITH] exists on current dev. SET DEFAULT [SMITH] else, append "$", treat as logical. SET DEFAULT SMITH$ Utilities in ICP Page 4 SMITH/DOC Build up logical name by replacing "/" with "$". Check if it translates. (This takes care of SYS$LOGIN) If it does not translate, append "$" to argument, and try again. SET DEFAULT SMITH$DOC$ Those who are familiar with the way the UIC task worked will see that this command procedure does exactly the same thing (although it takes much longer to run!!). Trying to simulate the WHO task as in indirect command procedure was much simpler, however due to the limitations of ICP, it was impossible to obtain full functionality. Basically, the WHO task gave a display very similar to the MCR command DEV /LOG, however WHO would display which tasks were active at each terminal and the status of each. This is very difficult (if not impossible) to get through ICP. The simulation of the WHO task when passing it an argument is also handled a little less cleanly. The task would take a string argument and match either the UIC or last name in the system account file and report the name and UIC. WHO could also match partial strings. For example, if the argument was "A", all last names in the system account file with last names beginning with "A" would be displayed, along with the corresponding default directory. The command procedure, not having the ability to scan the account file, simply opens the SYSLOGICS.CMD file and reads it as a text file, checking for a partial match with the logical name, and reporting the logical name and associated translation. Advantages of Using ICP _______________________ 1.) For privileged task simulation, it is crash-proof. 2.) For privileged task simulation, doesn't have to be rebuilt after every SYSGEN. 3.) Often much easier to write and implement. Disadvantages of Using ICP __________________________ 1.) Depending on complexity, it is often impossible to maintain full functionality. 2.) Often depends on ancillary files, as in the examples of WHO and UIC depending on the file SYSLOGICS.CMD and the logical names it creates. 3.) Slow speed and system overhead. Utilities in ICP Page 5 Conclusions ___________ Although it is often impossible for an indirect command procedure to faithfully emulate a privileged or non-privileged task, it may be worthwhile in cases where some functionality and execution speed can be sacrificed. Simulation of a privileged task by a command procedure is also convenient on installations which have only a production system, on which system crashes during privileged task development cannot be tolerated. The command procedures UIC.CMD and WHO.CMD as I have described them here, along with several other command procedures you might find useful will be included on the Fall 1986 RSX SIG tape.