| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 4222.1 | | CPEEDY::wells.lkg.dec.com::wells | Phil Wells | Mon Mar 24 1997 09:59 | 5 |
| I am not sure I understand the question, but there is a command
procedure we shipped SYS$MANAGER:PWRK$SHOWSYS.COM which selects the
PW processes from a SHOW SYS.
Phil
|
| 4222.2 | Goal is to Reduce Support Calls | VMSNET::P_NUNEZ | | Mon Mar 24 1997 11:01 | 22 |
| Phil,
I guess, basically, what we'd like to know is why do any of the
PATHWORKS processes have to execute SYLOGIN.COM during startup? If
there's a way to avoid it, we could eliminate the calls to the CSC
which result from PATHWORKS startup hanging because of some command in
SYLOGIN.COM that expects terminal input (ie, $ INQUIRE).
We've never seen a case where a command in sylogin.com was necessary to
start PATHWORKS; however, we DO get calls on commands in sylogin.com
hanging the startup of PATHWORKS. We resolve these with the IF
F$GETJPI call to check for a jobtype of 0 (detached process) and exit
if true. But, obviously, PATHWORKS isn't the only product which uses
detached processes, so for some customers, this workaround isn't so
simple.
Or is it by design that one cannot start a detached process w/o
executing SYLOGIN.COM?
thanks,
Paul
|
| 4222.3 | Yes | VMSNET::L_GULICK | Lew Gulick | Mon Mar 24 1997 11:36 | 12 |
|
> Or is it by design that one cannot start a detached process w/o
> executing SYLOGIN.COM?
It's part of VMS. The detached process is a separate process and thus
invokes sylogin.com as all other processes do.
Sylogin should be able to check the process names, but this will be
highly variable and might require a lot of upkeep. Still thinking
about this one.
Lew
|
| 4222.4 | VMS design 'feature' | CPEEDY::VATNE | Peter Vatne, PATHWORKS for UNIX Server Engineering | Mon Mar 24 1997 11:38 | 11 |
| > Or is it by design that one cannot start a detached process w/o
> executing SYLOGIN.COM?
I seem to remember from my discussions with Mike Maffa that it is
impossible to start a detached process with a CLI without executing
SYLOGIN.COM. I also remember that we petitioned VMS for a flag in
the $CREPRC service to say "don't run SYLOGIN.COM please". I don't
believe VMS has implemented such a flag. You are correct that it has
there is no need for us to run SYLOGIN.COM for the PATHWORKS detached
processes, and in fact it has been a constant source of problems from
day 1.
|
| 4222.5 | Now we know... | VMSNET::P_NUNEZ | | Mon Mar 24 1997 12:26 | 12 |
|
I at first thought it might be possible based on faint knowledge of the
/NOCOMMAND qualifer one can specify at the Username: prompt when
logging in interactively.
However, I believe even that doesn't bypass SYLOGIN.COM, just one's
LOGIN.COM.
At least we've got something to tell customers...thanks.
Paul
|
| 4222.6 | | CPEEDY::wells.lkg.dec.com::wells | Phil Wells | Mon Mar 24 1997 13:03 | 4 |
| Peter has is right - we requested this functionality from VMS but
they declined.
Phil
|
| 4222.7 | Right idea, wrong lexical - use F$GETDVI | HYDRA::MOORE | Windows-95% | Thu Apr 03 1997 16:28 | 6 |
| If you want to limit commands to be executed only when the process is
attached to a terminal, then write the procedure to test for that
condition:
$ if f$getdvi("SYS$COMMAND","trm") then .... <user interface available>
|