| T.R | Title | User | Personal Name
 | Date | Lines | 
|---|
| 463.1 | Workaround | VISA::BIJAOUI | Tomorrow Never Knows | Tue May 05 1987 14:29 | 4 | 
|  |     
    Why don't you check if BANNER is runnin' or not ?
    
    Pierre.
 | 
| 463.2 |  | EDWIN::WATERS | Lester Waters | Tue May 05 1987 14:45 | 20 | 
|  |     Well, that is a great idea, but I haven't been able to figure
    out how to get the PID for BANNER.  If BANNER was started from
    SYSTEM account, then F$PID() will not return a PID number that
    you can check, unless you have priv's.  This is going in SYLOGIN.COM
    
    What I tried:
    
    		$ CONTEXT = ""
    		$loop:
    		$ pid = f$pid(CONTEXT)
    		$ if pid .eqs. "" then goto done
    		$ pidname = f$getjpi(pid,"PRCNAM")
    		$ write sys$output "Process ''pid' is ''pidname'"
    		$ goto loop
    		$done:
    
    Of course, if f$pid() let me go through all pid's, then I could
    check for BANNER running.  Is there a function that will return
    the PID or TRUE/FALSE given a process name?
    
 | 
| 463.3 |  | ALBANY::KOZAKIEWICZ | You can call me Al... | Tue May 05 1987 15:48 | 12 | 
|  | Does the mailbox writer hang every time, or only after a while?  The reason
that this usually happens is that not reading the mailbox eventually consumes
whatever dynamic memory was set aside for the device.  This can be verified
by looking at the process of the writer - it will be in a RWAST (resource
wait) state.  If I was doing the write from a program, I would be doing
2 things.  First, use a QIO instead of a QIOW.  Second, call the system service
SYS$SETRWM.  This will cause the QIO to return an error instead of waiting
for the resource to become available.  I don't know what your options might
be from DCL. Since SYS$SETRWM sets the mode for the process, perhaps you
can write a short program to set this and run it inside your command
procedure.  Hope this helps somewhat....
 | 
| 463.4 |  | CAFEIN::PFAU | Now where did I leave my marbles? | Tue May 05 1987 18:51 | 6 | 
|  |     F$GETDVI(device,"REFCNT") might help.  It tells you how many channels
    are assigned to the device.  If the banner program is normally the
    only one having a channel assigned, the reference count will be
    1 if it is running, 0 if not.
    
    tom_p
 | 
| 463.5 | Hmmm...  but... | EDWIN::WATERS | Lester Waters | Tue May 05 1987 22:05 | 8 | 
|  |     F$GETDVI(device,"REFCNT") is a help, but the reference count may
    still be non-zero (as in the case where DISPMSG - display message
    thing) is running.  So a non-zero refcnt could mean that BANNER
    is running *or* BANNER died and the dispmsg is still running.  It
    is not guaranteed that BOTH (REFCNT=2) will always be running.
    
    Interesting challenge...
    
 | 
| 463.6 | hack, hack, hack,... | CHOVAX::YOUNG | Back from the Shadows Again, | Tue May 05 1987 23:34 | 17 | 
|  | 
    $!
    $! Determine if BANNER is running
    $!
    $ Banner_running := TRUE
    $ Temp_name := 'f$pid(0)'
    $ Temp_file = Temp_name + ".temp"
    $ Show System /output='temp_file'
    $ Search 'temp_file' BANNER /nooutput /nolog /nohead
    $ If ($severity .nes. "1") then $ Banner_running := FALSE
    $ Delete 'temp_file';0
    $!
    $! Now take action depending on whether Banner_running is TRUE or FALSE
    $!
    $...
    --  Barry
 | 
| 463.7 | Funny I can tell with privs off | FROST::HARRIMAN | Too much talk, Small Talk | Wed May 06 1987 09:30 | 12 | 
|  |     
    Just 'cause you got no privs doesn't mean you can't find out if
    a process exists via DCL. F$GETJPI is nice enough to tell you "%W,
    no privilege for attempted operation" if the process exists, and
    "%W, no such process" if it isn't there in the first place. Since
    the errors are still trappable (and you can get $STATUS back for
    them at least this version of VMS) you could get away with your
    original try as long as you inhibit message output during SYLOGIN.COM.
    
    just a suggestion
    
    /pjh
 | 
| 463.8 | how about SPAWN/NOWAIT | VIDEO::OSMAN | type video::user$7:[osman]eric.six | Wed May 06 1987 10:45 | 10 | 
|  | Two suggestions to avoid hanging on mailbox operations from DCL:
o	Experiment with the /TIMEOUT=0 switch on dcl's READ command.`
o	Use SPAWN/NOWAIT @WRITE_TO_MAILBOX instead of just @WRITE_TO_MAILBOX.
	That way, if it hangs, so what.  It's just the subprocess that hangs,
	not your entire terminal.
/Eric
 | 
| 463.9 | SPAWN/NOWAIT & undesirable side effect | UTRTSC::ROBERTS | UTO-23.9b, DTN 838-2679 | Thu May 07 1987 04:14 | 3 | 
|  |     In V4.3 and V4.4 there were "certain disadvantages" with the
    SPAWN/NOWAIT DCL command. I don't know if V4.5 fixed the problem
    or not. 
 | 
| 463.10 | You can play with resource wait from DCL | MAKO::NELSON | Jeff E. Nelson | Thu May 07 1987 08:58 | 28 | 
|  |     RE: a couple of replies back.
    
    You can enable and disable resource wait mode from DCL.  Here's
    the info from HELP:
    
    SET
    
      PROCESS
    
        /RESOURCE_WAIT
    
         /RESOURCE_WAIT
         /NORESOURCE_WAIT
    
          Enables or disables resource wait mode for the current process.
    
          If you specify /NORESOURCE_WAIT, the process will receive  an  error
          status  code when system dynamic memory is not available or when the
          process exceeds one of the following resource quotas:
    
               Direct I/O limit
               Buffered I/O limit
               Buffered I/O byte count (buffer space) quota
    
    Doesn't look like it will help, but it's worth a try.
    
    				JENelson
 |