PJS@NAIF.JPL.NASA.GOV (Peter Scott) (04/22/88)
Any command that I have defined in my session with a "SET COMMAND <filename>" command is unknown to a subprocess that I create with "SPAWN/NOWAIT". Since I would like to do background processing with these commands, the only way I know to make the commands available would be to spawn a command procedure that contained the SET COMMAND command. This would usually take enough time that it takes the edge off the efficiency I am aiming for. Is there another solution that lets me type "SPAWN/NOWAIT <command>"? Peter Scott (pjs%grouch@jpl-mil.jpl.nasa.gov)
LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU) (05/17/88)
Any command that I have defined in my session with a "SET COMMAND <filename>" command is unknown to a subprocess that I create with "SPAWN/NOWAIT". Since I would like to do background processing with these commands, the only way I know to make the commands available would be to spawn a command procedure that contained the SET COMMAND command. This would usually take enough time that it takes the edge off the efficiency I am aiming for. Is there another solution that lets me type "SPAWN/NOWAIT <command>"? Define your own command table by using a command like: $ SET COMMAND yourdefs/OUTPUT:yourtable/TABLE:SYS$SHARE:DCLTABLES This will create a command table named YOURTABLE.EXE which contains all the commands in the standard table, plus your modifications. You can then use that table in either of two ways: To replace the tables in your current process, do $ SET COMMAND/TABLE:yourtable This is MUCH faster than running through the CLD file each time. To spawn a subprocess using your private tables, you can do: $ SPAWN/TABLE:yourtable Unfortunately, this requires that YOURTABLE be installed. You must also provide a specification that will make sense in the created process BEFORE process logicals are copied - i.e., either provide a full device/directory spec, or get them from a job- or group- or system-wide logical. You can select your own table at login time by including a /TABLE qualifier on your username. Again you'll probably have to include an explicit disk and directory - the default is SYS$SHARE. In fact, you can even have your system manager update your SYSUAF entry so that your DEFAULT table is your private table - in which case batch jobs, spawned jobs, and so on will use your private table automatically. There are a couple of drawbacks with this approach that you should be aware of: 1. When the system-wide DCL tables are updated, your private copy will NOT be updated; so newly-installed products may not work, and when VMS itself is updated, old stuff may start to fail. You'll have to build a new copy of your private table when this happens. (Note that if you have your private table set up as your default, you may not even be able to log in - unless you add /TABLE=DCLTABLES to return to the system default tables. Beware: If your account is also marked /CAPTIVE, you will not be allowed to specify the /TABLES qualifier, and your system manager will have to come to your rescue!) 2. The tables are sizeable - 300 blocks or so. 3. This is a problem, not so much with this approach, as with SET COMMAND itself: DCLTABLES.EXE is shared; but a private table - and that includes the anonymous private table a simple SET COMMAND creates for you - is NOT shared. So having a lot of people with private tables wastes memory. These days, that's increasingly not worth worrying about - but there are yet many systems where having every process chew up an extra 300 pages of memory would be painful. In that case, if any sort of agreement can be reached about what extensions people would like to see, the best thing to do is create a new table with these extensions defined, INSTALL it /SHARED, and let people use it that way. -- Jerry
carl@CITHEX.CALTECH.EDU (Carl J Lydick) (05/17/88)
> Any command that I have defined in my session with a "SET COMMAND > <filename>" command is unknown to a subprocess that I create with > "SPAWN/NOWAIT". Since I would like to do background processing with these > commands, the only way I know to make the commands available would be to > spawn a command procedure that contained the SET COMMAND command. This > would usually take enough time that it takes the edge off the efficiency I > am aiming for. Is there another solution that lets me type "SPAWN/NOWAIT > <command>"? That depends on whether you have CMKRNL priv or on how friendly a system manager you have. If, when you modify your process's command tables with the SET COMMAND command, you make a copy of the new tables on disk via a command of the form $ SET COMMAND/TABLE=old_table/OUTPUT=new_table cld_file then install the new command table (/OPEN/HEADER/SHARE), you can use the command: $ SPAWN/TABLE=new_table to have your subprocess start out with the new commands already defined. On the other hand, I don't understand why you think the SET COMMAND command is slow, unless you're having it parse the human-readable definitions in .CLD files each time; if that's the case, you should be quite happy to learn about the other variations of the SET COMMAND command. The one described above generates a file containing a new set of compiled command tables. The command $ SET COMMAND/TABLE=new_table replaces your process's old command tables with those found in the new table. Replacing the whole set of command tables this way takes only about three seconds on a moderately loaded 780.