batch on RT11 w/TSX+
Jerome H. Fine
jhfinedp3k at compsys.to
Thu Jan 19 16:43:45 CST 2006
>Lyle Bickley wrote:
>>On Wednesday 18 January 2006 13:34, Jerome H. Fine wrote:
>> >Jay West wrote:
>>>I was wondering if somone knew the answer to this... is BATCH
>>>supported on RT11 that is running TSX+? I know it's supported on RT11,
>>>but I thought I saw somewhere that once you loaded TSX+ that you
>>>couldn't run BATCH because of some conflict. Anyone know the straight
>>>scoop on this?
>>Jerome Fine replies:
>>Under RT-11, BATCH is supported via the BA(X).SYS
>>device driver, as well as other hooks in the operating
>>When TSX-PLUS is run, the Resident Monitor (RT11XM)
>>is completely replaced along with the Keyboard (KMON)
>>and the User Service Routine (USR). There are also
>>minor changes to some of the device drivers. Most
>>of the utility programs run as is without change.
>Yes - except that SETSIZ.COM is run (executing SETSIZ.SAV) as part of the
>install process, and modifies the RT utility binaries to include the actual
>amount of memory required for them to run under TSX+. (BTW, the utilities
>work fine with RT-11 after the "patch").
Jerome Fine replies:
In my reply, I was attempting to emphasize for those who were not
aware just how different the TSX-PLUS code is from RT-11. And
while I agree that the SETSIZ.SAV program helps TSX-PLUS to
know a bit more information than is supplied by the RT-11 linker
(LINK.SAV - or at least I presume that is the case) and that the
utility binary, or any other application SAV file for that matter, has
a word or two added for that purpose. I never was interested
enough to do a BINCOM comparison before and after to see
exactly what was done.
>>Since there is no BA.TSX device driver, you can't
>>run BATCH under TSX-PLUS. Part of the reason may
>>be that SL: (the RT-11 Single Line Editor - similar
>>to some of the stuff done by DOSKEY in DOS) is built
>>into TSX-PLUS rather than being a separate device
>>driver as in RT-11 which uses SL(X).SYS to perform
>>the functions. Since SL: and BA: can't run at the
>>same time in RT-11 and since SL: seems to be built
>>into TSX-PLUS, perhaps that is part of the reason
>>that BATCH is not supported.
>SL can be removed from TSX as part of the install (TSGEN) process. However, as
>you stated, a BA.TSX is not present and therefore "batch" is not even "seen"
I tend to remember that there is an OBJ module (part of one of the
large OBJ (non-library) TSX-PLUS files for the SL code. Running
LIBR provides the names of all of the modules in each OBJ file.
I did that once when I had to transfer an actual patch from V3.1
of TSX-PLUS to V6.5 of TSX-PLUS as part of a Y2K upgrade.
>The System Manager's Guide says "The following RT-11 device handlers are
>unsupported under TSX-Plus: BA (resident batch handler), EL (error logging
>pseudohandler), and PD (PDT-11/130/150 handler). The ethernet drivers, NC,
>NQ, and NU are not supported. Also the IBSRQ function of the GPIB IEEE IB
>handler is unsupported."
I find it very annoying when a company used the same description
to apply to software components that had been tested and seem
to work and others that were known to completely fail. That seems
to be what was normal in the 1980s - now I guess it is even worse
since now even components written by the actual manufacturer also
completely fail, under often normal conditions.
Of course, RT-11 still does that as well, just not as often since most
of the bugs are gone. What about TSX-PLUS bugs. I don't know
of any right now. Looking at the code might turn up a few! That
is how I found one of the fatal bugs in RT-11, although I admit I
was looking at that code which causes the crash because a device
driver written by DEC caused the same crash to occur when certain
similar conditions were present.
>>However, I doubt if
>>anyone knows the internals of both RT-11 and TSX-PLUS
>>sufficiently to comment.
>That is almost correct ;-)
>I've been spending a fair amount of energy studying the internals based on the
>TSX-Plus "Programmers Reference Manual", "System Manager's Guide" and the
>"User's Reference Manual". I've also been asking a LOT of questions on the OS
>from the person who architected TSX and ran the company who developed and
>sold the product. I figure that when I release TSX-Plus, I'll essentially be
>as close to "tech support" as we can have for a while - along with all the
>folks who have been playing with licensed versions of the software for years.
>Even though almost all of the source code was lost (I found some scattered
>pieces on the development Fujitsu 2312 drive). I did pay do have all of the
>TSX-Plus listings (4 boxes worth!) shipped to me here in California. I passed
>them on to Al Kossow (bitsavers.org) so he could scan them and make them
>available to the world (I have permission from the owner to do so). So at
>some point we'll all have all of the "internals" :-)
I had been aware for some time that the listings were still around.
The comments on the code should be priceless for individuals who
are still running TSX-PLUS. However, I very much doubt that the
code contains ALL of the "internals". Surely there must have been
internal manuals as well, just as there must have been with RT-11.
However, because a TSX-PLUS SYSGEN was done using the
OBJ files, a great deal of information is still available in what are
essentially machine readable source files - BUT WITHOUT
COMMENTS. The trick is to convert those OBJ files into
MAC files without comments. The only application from DECUS
which ever came close was UNMAC. The DECUS version was
reasonable as far as the code was concerned, it just can't handle
the normal TSX-PLUS OBJ modules due to the HUGE number
of GLOBALs - at last count I seem to remember over 1600 when
I attempted to UNMAC the module TSUSR.OBJ in TSX2.OBJ
again if my memory has not failed. If anyone is ever interested
in reproducing the MAC files and scanning the listings could use
extra help in the form of uncommented source, let me know.
>In the meantime, the TSX-Plus manuals do describe in detail how to modify
>DEC's handlers for operation under TSX-Plus - and a fair amount of detail on
>TSX-Plus internals. The more I study, the more I'm impressed with this OS!!!
I also am VERY impressed. BUT, looking at the code for TSUSR.OBJ
leads me to consider that the code was produced subject to rules which
only TSX-PLUS programmers knew about. Certainly, this one example
uses a lot of extra words that are not needed for normal coding. There
must have been very good reasons why so many extra words were used.
By the way, the reason I looked at the code for TSUSR was that I
wanted to add the extra hooks that I had added to the RT-11 USR.
>From what I saw, I doubt that TSX-PLUS handles physical device
names in the same manner as RT-11. So where it is possible to tell
RT-11 to override:
ASSIGN DL3: DX0:
and use the actual physical DX0: drive instead, I don't know how to
do that under TSX-PLUS when there is an actual physical RX01 drive
on the hardware and there is a reason to use the physical RX01 drive
in addition to the ASSIGN symbol of DL3: during the course of executing
a specific program.
RT-11 probably had internal manuals which were never released (and might
now have been lost) that might still be available via the development team
members who with RT-11 in 1992 when V05.06 of RT-11 was finally
released on August 31st, 1992 after which DEC placed RT-11 on
life support - or lack of life support depending on which side of the
fence you are on.
Likewise I would assume that TSX-PLUS had internal manuals as well.
Did any NEVER published manuals turn up in addition to the source listings
and the standard published manual set from S&H for TSX-PLUS of
about 4" of paper? I have several original sets for versions of TSX-PLUS
prior to V6.5 of TSX-PLUS in addition to the manual set for the last
V6.5 of TSX-PLUS.
What I don't have is any of the applications or manuals.
>>Does this information provide enough of an answer?
>>The answer Lyle suggested provides an alternative.
>>A command file can be used to run the job, but
>>the results might not be quite the same. On the
>>other hand, once BATCH is running under RT-11,
>>can you use the background job? Since I don't
>>use BATCH myself (anything I want done I am not
>>able to continue with anything else, so a command
>>file is sufficient), please let me know if KMON
>>is still available to the user? If only system
>>jobs can still be run, that is not very useful.
>Since detached jobs, spooling and indirect command files are available under
>TSX-Plus, my guess is that anything you could do with Batch under RT would be
>"doable" under TSX-Plus (with some modification to the batch file).
In a few cases, a LOT of modifications to the batch file.
In most cases, likely very little and quite easy to do!
I never bothered much with batch files, so I can't really
comment. The really big advantage with TSX-PLUS is that
running a command file in even a normal job will not
interfere much, if at all, with an interactive job when
the job priority is set up for that situation. I can't
remember right now how it is done, but I seem to remember
that any privileged job could set the priority of any job,
including its own priority.
Does a BATCH file under RT-11 run in the background job?
I don't have the manuals in my lap, so asking for help
By the way, I again doubt if anyone is interested, but
I can now calculate the natural logarithm of 16 bit
integers when done in sequence with a precision of
about 150 decimal places. The next goal is to calculate
li(10**n) for n up to 100. The basic requirement for
li(x) is log(x) and log(log(x)) in addition to the
inverse of n (i.e. 1/n) up to about n = 5000, I do not
anticipate any further technical difficulties. The
only likely problems are roundoff and / or truncation
errors which could be larger than anticipated. If
there is any interest, please ask a question. Very
quickly, for those who don't remember:
log(10**n) = n * log (10)
log(log(10**n) = log(n) + log(log(10))
I expect that very soon I will find out at what value
of k the expression:
becomes less than 1/2**512. As an estimate, I know that
34! > 2**128 since that value overflows with REAL * 8
floating point values.
If you attempted to send a reply and the original e-mail
address has been discontinued due a high volume of junk
e-mail, then the semi-permanent e-mail address can be
obtained by replacing the four characters preceding the
'at' with the four digits of the current year.
More information about the cctech