Conference iosg::all-in-1_v30

Cyn,

A1SUB.LOG is the SYS$OUTPUT and SYS$ERROR of the subprocess of an ALL-IN-1 job
running in batch.  It really can't be avoided, at least not in ALL-IN-1 V2.4
and before.  The only way to "fool" this is to have your batch command procedure
find some way to point its SYS$OUTPUT to a (true) terminal device before running
ALL-IN-1.  A $GETDVI of SYS$OUTPUT must be DC$_TERM to avoid the A1SUB.LOG.

Whether this is still true for V3 I don't off hand know.

/Marty

    ... and this behaviour is unlikely to be changed.


    However, when you get V3.0 I suggest you check out the `script symbiont'
    which provides an ALL-IN-1 batch type facility.

    Paul.

    
    	I never did understand why the subprocess output doesn't go to
    	the batch log file instead of to A1SUB.LOG. Perhaps a fellow
    	engineer could enlighten me. It would certainly help debugging.
    	My guess is that it is something to do with process permananent
    	files, file sharing and the like, which makes it impossible for
    	the A1 process and the subprocess to share the same logfile.
    
    	This has not changed in V3.0.
    
    	You could try things like setting a version limit on A1SUB.LOG or
    
    	$ DEFINE A1SUB.LOG NL:/system/exec
    
    	or something along those lines, but don't be surprised if ALL-IN-1
    	gets upset. By the way, you NEED A1SUB.LOG to debug scripts
    	submitted to batch.
    
    Regards,
    Paul

You guessed it Paul.  The $CREPRC doesn't "allow" any way for LOGINOUT to be
passed the same output stream that is currently opened.

And because of how $CREPRC does its thing, a logical for A1SUB.LOG would have
to be system-wide, and even then may not work, and you wouldn't want to have
A1SUB.LOG pointed to anything for very long, as other batch jobs may need
to have a "real" A1SUB.LOG written to for their processing.

/Marty

    Okay, maybe I'm missing something obvious, but if I create a batch job
    like this:
    	$ spawn/nowait show sys
    	$ show sys
    Then the output looks like this:
     %DCL-S-SPAWNED, process LANPHEAR_1 spawned
     VAX/VMS V5.5  on node KUDZU  28-FEB-1992 12:02:50.05   Uptime  11 20:00:50
       Pid    Process Name    State  Pri      I/O       CPU       Page flts Ph.Mem
     VAX/VMS V5.5  on node KUDZU  28-FEB-1992 12:02:50.06   Uptime  11 20:00:50
       Pid    Process Name    State  Pri      I/O       CPU       Page flts Ph.Mem
     24400101 SWAPPER         HIB     16        0   0 00:08:59.36         0     0
     24400101 SWAPPER         HIB     16        0   0 00:08:59.36         0     0
     ...
    
    which proves that two processes can simultaneously write to the same log 
    file.  I understand that ALL-IN-1 isn't playing by the same rules in
    that the subprocess isn't a normal subprocess, but it seems like log
    file sharing shouldn't be impossible, given the right level of share
    privileges...
    
    Either way, it isn't going to change, so I suppose this is a rat hole.
    
    						Cheers, Dan'l

Two (or more) processes can write to the same SYS$OUTPUT channel, but only when
they know what the channel is!  In your SPAWN case, the subprocess has the
internal stream identifier for the output stream as part of its inherited
SYS$OUTPUT and SYS$ERROR logicals.  It works great!

In the case of $CREPRC where LOGINOUT is executed, a new process is created that
can't get that stream id, because it doesn't inherit any logicals (or anything
else) from the parent.

/Marty

    
    Thanks for all the explanations! I guess I'll just delete the old log
    file everytime the procedure is started. 
    
    Cyn