| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 500.1 | | UFP::MURPHY | European or African Swallow? | Mon Jun 15 1987 20:59 | 5 |
| The service is called SYS$CREPRC. Run it with INPUT pointing to
a command file, OUTPUT to a log file, and specify the image
SYS$SYSTEM:LOGINOUT.EXE. This will create a 'detached' process with
DCL mapped.
-Rick
|
| 500.2 | | MARVIN::PALKA | | Tue Jun 16 1987 12:54 | 13 |
| re .1
I dont think this is sufficient, it does not explain how to pass
the command line to the new sub process.
You can do it by running a second image which reads up the current
command line (either by reading it and hacking out the /DETACH or
by reconstructing it from the results of several calls to DCL)
and then calls LIB$SPAWN to create the subprocess. This will have
the effect of doing a SPAWN command.
I dont know of any way to get DCL to do the SPAWN directly.
Andrew Palka
|
| 500.3 | Can not be a sub-process | TSG::KARDON | | Tue Jun 16 1987 13:00 | 7 |
| re .2
I don't want to create a sub-process. I want a process that will
stick around when its creator logs out (hence the detached process).
Thanks and keep those ideas flowing,
-Scott
|
| 500.4 | Command Line is only input from user | TSG::KARDON | | Tue Jun 16 1987 13:08 | 10 |
| I don't know if this will make things a little more obvious. My
program does not get any input from its user. It just hangs out
in its own (hopefully detached) process and I/O is performed upon
it by other processes writing to a mailbox that it is monitoring.
All I want to do is to be able to use the CLI to set up its environment
inside of the detached process.
-thanks again,
Scott
|
| 500.5 | | UFP::MURPHY | European or African Swallow? | Tue Jun 16 1987 18:27 | 15 |
| Maybe this will help.
When your user types: $VERB/DETACH/OTHER_QUALIFIERS
You open a temporary file. Call it VERB_DETACH.COM.
(Maybe you could qualify the filename with the user's PID. Whatever.)
Set up the CLD file so that the /DETACH qualifier sets up an alternate
syntax entry with one parameter, type=$REST_OF_LINE. Now, when you
see /DETACH, your routine grabs P1, appends the VERB to it, and
writes that verb to the temporary file.
Create the detached process running LOGINOUT with the /INPUT pointed
to your magic temporary file. You can even have the file delete
itself, as it won't really go away until it is closed.
Does this make it clearer?
-Rick
|
| 500.6 | Why even map DCL? | FROST::HARRIMAN | $GETJPI-yi, $GETJPI-yo | Wed Jun 17 1987 12:11 | 32 |
|
Courtesy of System Service Description (SYS-83)
" A created process will be unable to run an image that calls the
Run Time Library procedure LIB$DO_COMMAND unless the process was
created with the IMAGE argument specifying SYS$SYSTEM:LOGINOUT.EXE.
This is true because SYS$SYSTEM:LOGINOUT.EXE causes a command
language interpreter to be mapped into the created process, a
prerequisite for calling LIB$DO_COMMAND."
The significance of this is not that you may or may not be using
LIB$DO_COMMAND. It is that the CLI does not exist unless you issue
a $CREPRC using LOGINOUT as the "program". Your SYS$INPUT specification
would then issue the "appropriate" DCL environmental commands and
invoke your application (or daemon).
Alternatively the RUN command can create a detached process (under
a suiably privileged user) and the process characteristics are mostly
available via it's syntax. This saves you the trouble of needing
SYS$INPUT defined as something other than NL:.
I wrote an application (daemon)? which has been running on our cluster
for over a year which basically receives mailbox messages to snapshot
activity on the major application which the system runs. The program
uses a mailbox to communicate with many other processes (about 200-250
a day). It is invoked via a command procedure and the DCL RUN command.
The environment by which the monitor runs has no CLI - however the
process characteristics were customized by the RUN invokation. The
monitor itself knows and sets up the rest of it's environment by
calling suitable system services (like $CREMBX and $CRELNM)...
/pjh
|
| 500.7 | If you want DCL, you have to use LOGINOUT | ERIS::CALLAS | I have nothing to say, but it's okay | Wed Jun 17 1987 12:26 | 9 |
| Sigh. If you want to create a detached process that has DCL mapped, the
way to do it is to do what Rick said in .1 and .5. Call $CREPRC with
LOGINOUT as its image and some command file. Note that you could easily
use a mailbox or a pipe for your file, so you don't have to go and play
file name games (instead, you get to play logical name games :-). If
you want DCL mapped into your process, you really have to get LOGINOUT
to do it.
Jon
|
| 500.8 | LOGINOUT -- yeah | TSG::KARDON | | Thu Jun 18 1987 21:45 | 4 |
| Yeah, it looks like LOGINOUT is the way to go.
Thanks for your comments.
-Scott
|
| 500.9 | SYS$SNDJBC | AKA::PARK | Crushed by the wheels of industry | Wed Jun 24 1987 12:43 | 12 |
|
Why not $SNDJBC to create a batch job? The batch job will have
DCL mapped (if DCL is specified as the CLI) and you can pass parameters
through SJC$_PARAMETER1, etc.
The created process will be a detached process. You will be able
to parse parameters by compressing the command line in the command
file that you would submit to the batch queue.
Just a thought.
-x
|