From: efricha@vortex.rti.org
Subject: Problem with detached/subprocess output files
Keywords: $PUTMSG, RUN/DETACHED, RUN/OUTPUT, $CREPRC, Process-permanent files
Organization: Tybrin Corporation
Date: 29 Sep 92 09:13:39 EST

We're having a big problem with mixing writes to SYS$OUTPUT and SYS$ERROR
when we don't have a CLI present to open them as process-permanent
files, such as detached or subprocesses started with $CREPRC or RUN.

Consider the following program:

	PROGRAM TEST1
	INTEGER A, B, C
	DATA B, C /1, 0/
	PRINT *, 'Hello...'
	A = B / C
	PRINT *, A
	CALL EXIT
	END

What happens when you run it interactively (or any way with a CLI in
support) is you get:

	Hello...
	%SYSTEM-F-INTDIV, arithmetic trap, integer divide by zero at
	PC=00000627, PSL=03C00022
	%TRACE-F-TRACEBACK, symbolic stack dump follows
	module name     routine name             line       rel PC    abs PC

	TEST1           TEST1                       5      00000027  00000627

Now try and run it as a subprocess or detached without a CLI:

	$ RUN/OUTPUT=TEST1.LOG/ERROR=TEST1.ERR TEST1

TEST1.LOG has only

	Hello...

in it, but not the error message.  The error message went to SYS$ERROR but
NOT to SYS$OUTPUT as it is supposed to.  The reason seems to be that
$PUTMSG (via the traceback handler) tried to open SYS$OUTPUT, found that it
was locked by another user, and failed quietly.  You'd never know that
anything went wrong without the /ERROR= param.

Not such a big problem?  Consider this case:

	PROGRAM TEST4
	INTEGER LIB$SHOW_TIMER
	CALL LIB$INIT_TIMER
	CALL LIB$SIGNAL(%VAL(1))
	CALL LIB$SIGNAL(%VAL(LIB$SHOW_TIMER()))
	CALL EXIT
	END

Interactively, you get a success message, a message from SHOW_TIMER,
and another success message:

	%SYSTEM-S-NORMAL, normal successful completion
	 ELAPSED:    0 00:00:00.07  CPU: 0:00:00.01  BUFIO: 1  DIRIO: 1  
	FAULTS: 7 
	%SYSTEM-S-NORMAL, normal successful completion


However, if you run as a subprocess as described above, your output file
has:

	%SYSTEM-S-NORMAL, normal successful completion
	%RMS-E-FLK, file currently locked by another user
	%TRACE-E-TRACEBACK, symbolic stack dump follows
	module name     routine name             line       rel PC    abs PC

	TEST4           TEST4                       5      0000002B  0000042B

You get other combinations if you mix in LIB$PUT_OUTPUT and FORTRAN WRITE
and PRINT statements.  The tests shown above were run on a V5.3-2 system.
Similar results occur on a V5.4-3 system.  I'd *THOUGHT* that at one time
this all worked -- if not as "desired" -- at least RMS would create separate
files for each output stream if it couldn't open them all for output at once
into the same file.

A suggestion given to me to solve this was to open SYS$OUTPUT and
SYS$ERROR with full file sharing, assuming that this would "force" the
other opens (done by $PUTMSG, etc.) to share as well, but RMS doesn't
work that way.

I also tried to open SYS$OUTPUT/ERROR as process-permanent files, but from
what I can see, it must be done from supervisor or exec mode.  I was trying
to avoid using privileges in this.

I guess, then, my questions could be summed up as:

	o  Is there a way to get these varied methods of sharing output
	   to write to the same file without CLI support?
	o  How do I open SYS$OUTPUT as a process-permanent file?
	o  Can I execute my own code thread in supervisor mode without
	   privileges or a CLI present?  How?

Eric Richards							 904/882-9793
Senior Software Engineer				richarde@eglin.af.mil
Tybrin Corp.
Eglin AFB, FL