[HECnet] Weird SUBMIT error

[Paul_Koning at Dell.com]

> 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:
>> 
>>> 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:
>>>> ...
>>>> 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?
>> 
>> 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.
> 
> 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.
> 
> 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