15 Sep
2015
15 Sep
'15
10:07 p.m.
On Sep 15, 2015, at 2:58 PM, Johnny Billquist <bqt
at softjar.se> wrote:
On 2015-09-15 20:50, Paul_Koning at Dell.com wrote:
Really nice. But was this something new in V9 or so then? I pretty much stopped using
RSTS/E at V8, and I can't remember anything like this.
Yes, I added that in V9.0.
On Sep 15, 2015, at 2:32 PM, Johnny Billquist
<bqt at softjar.se> wrote:
On 2015-09-15 20:28, Paul_Koning at Dell.com wrote:
Yes:
$ open/logfile/time foo.log...
The way this works is that the log file (and current command file level) are owned and
handled by the kernel. The indirect command processor just opens the files and hands them
to the kernel. If a command file is open, the kernel directs terminal reads to that file.
If a log file is open, it sends terminal output to the log. Also, if requested, it
prefixes a timestamp. These are called "permanent files" because they
aren't closed at program exit the way regular file descriptors are.
So most of the work of batch jobs (and command files) is in the kernel. That's about
the only way to make it transparent, since RSTS doesn't have supervisor mode in which
to hide DCL concurrent with the running process, as VMS does. ...
Or RSTS/E people... where it's even neater because you can do stuff like "give
me a log file" interactively -- it was created for the benefit of batch but it is
part of the kernel machinery for talking to a process ("job"), so it isn't
only batch.
Well, my comment was specifically about the non-need for a $JOB. In RSX, batch will be
very unimpressed if you skip the $JOB.
But now you got me a bit curious. So you can essentially ask for a log file of whatever
terminal that is doing something, at any point in time?
The way to accomplish this in RSX would essentially be to run all your commands in a
virtual terminal, and output the results both to the terminal and a logfile. However,
there are some subtly differences that happens if done that way. So I can't say that
you really can accomplish this in RSX.
RSTS used to do it that way. The trouble is that we really wanted to be able to do stuff
based on "exit status". And in RSTS that wasn't always well defined. Yes
for RSX based programs, but not for others. So we did this by watching the output for
error messages. Also, the virtual terminal based approach means you need two job slots:
one for the controller, and one for the controlled. With job slots often being in short
supply, that wasn't desirable. The question became "can the kernel do this so we
don't end up using scarce system resources" and the answer turned out to be yes.
paul