| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 621.1 | lib$spawn () | FOO::BHAVNANI | It's not a bug - it's a feature! | Sat Dec 05 1987 02:05 | 5 |
| I don't have an RTL manual handy, but I'm pretty sure that one
of the values for the (optional) flags mask arg to lib$spawn()
tells it to copy the parent's logical name tables to the
spawned proc.
/ravi
|
| 621.2 | | BOLIVR::PARK | silence means approval | Sat Dec 05 1987 19:22 | 14 |
|
lib$spawn only allows you to copy logical name tables and cli symbol
tables to the created process. It doesn't allow the copying of
command tables.
Alternatively, as the subprocess' input file, you could have something
like:
$ set command <foo>
$ loop:
$ read/prompt=f$environment("prompt") sys$command line
$ define/user sys$input sys$command
$ 'line
$ goto loop
|
| 621.3 | | PASTIS::MONAHAN | I am not a free number, I am a telephone box | Tue Dec 08 1987 05:57 | 6 |
| Have you tried getting your system manager to set your own CLI
tables in SYSUAF?
I think that carries over to subprocesses, and it would make your
main process startup faster too, rather than processing the .CLD file
every time.
|
| 621.4 | | SMAUG::MENDEL | Pessimists Always Get Good News. | Tue Dec 08 1987 13:25 | 14 |
| As in -
- copy SYS$LIBRARY:DCLTABLES to my local directory?
- applying the .CLD to my local table just once?
- change UAF so that /CLI_TABLES points to the new table?
and Presto?
If this would work (would it?) then that would be excellent.
Thanks.
|
| 621.5 | Yes, except the tables must be in SYS$LIBRARY and INSTALLed | JON::MORONEY | Question Authority (and the Authorities will question you) | Tue Dec 08 1987 13:38 | 0 |
| 621.6 | INSTALL - yes, SYS$LIBRARY - no | MONSTR::DUTKO | Nestor Dutko, VMS/VAXclusters CSSE | Tue Dec 08 1987 15:24 | 7 |
| Not exactly correct. You are correct in that the new DCLTABLES
have to be INSTALLed, however, they do not have to be in the
SYS$LIBRARY directory. You can specify an alternate device and
directory specification for /CLITABLE in the UAF and it will be
searched.
-- Nestor
|
| 621.7 | | PASTIS::MONAHAN | I am not a free number, I am a telephone box | Tue Dec 08 1987 16:43 | 3 |
| OOps, yes, sorry. You must get your system manager to install them too,
as well as modify SYSUAF. Otherwise there are nasty obscure security
loopholes (that is, you might be fooled into using the wrong tables).
|
| 621.8 | | SMAUG::MENDEL | Pessimists Always Get Good News. | Tue Dec 08 1987 17:12 | 4 |
| Hmmm... I don't think .4 thru .7 represents a viable solution.
INSTALation is for important things, and I'm just a little cog.
Thanks, everyone! ... but don't stop now!
|
| 621.9 | nit | DELNI::CANTOR | Dave C. | Tue Dec 08 1987 23:16 | 7 |
| Big VMS gurus correct me if I'm wrong, but I think that
DCLTABLES.EXE is specified to be in SYS$SHARE, not SYS$LIBRARY.
It just so happens that SYS$SHARE and SYS$LIBRARY are logical
names which translate to the same directory in a vanilla VMS
installation.
Dave C.
|
| 621.10 | | CLT::GILBERT | Builder | Sat Dec 12 1987 13:20 | 1 |
| Ask your system manager to add *your* commands to the system DCLTABLES.
|