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
system.
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"
by TSX+.
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
is faster.
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:
[log(10**n)]**k/k!
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.
Sincerely yours,
Jerome Fine
--
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.