Johnny Billquist wrote:
"Jerome H.
Fine" <jhfinedp3k at compsys.to> wrote:
I would not assume anything until I actually had
tested the presence
or absence of a
specific "feature".
What have any features have to do with this?
I'm telling you that RTEM-11 will not, and never have been capable of
running on a VAX.
If there was a RTEM product for the VAX, it would have to be a
separate product, with a separate code base from RTEM-11, since you
cannot write a RT-11 emulator of any kind in PDP-11 mode on a VAX. It
will have to be VAX code. And thus, it can not be the same product as
a RT-11 emulator program written to run under RSX.
I agree that it is obvious that the RTS code will be written in the native
instruction set of the system under which the RTS is running. That means
that the RTS system under RSTS/E executes PDP-11 instructions and
uses RSTS/E EMT requests. As you state, under VMS and a VAX,
VAX instructions are used. And if I may push the envelope a bit, under
SIMH, x86 instructions are used if we agree to call SIMH or E11 a RTS
of a different kind, although the more descriptive name is emulator.
My reference to a specific "feature" is with respect to the actual
details of
the RTS in question. For RSTS/E, the RTS to handle RT-11 EMT requests
does not support even all of the RT-11 EMT requests which the RT11SJ
monitor in RT-11 supports. For example, the .CStatus request is ignored
and the .SaveStatus request return the "dev:filnam.typ" and [PPN] for the
file in question rather than the five Channel Status words used in an RT-11
environment. So there are significant differences between the RT-11 RTS
under RSTS/E and an actual RT11SJ monitor running under a PDP-11
instruction set (specified so as to include both a DEC CPU and an emulator
such as SIMH).
>> In
addition, I also suspect that both Johnny and Ethan are
correct in >> that RTEM
>> was supported under both RSX and VMS on an older VAX which allowed
>> compatibility mode.
> It would have to be totally separate products in that case.
AGREED!!
Thank you. Now we can proceed.
>> I don''t know if Megan Gentry is
still around or perhaps Allison
or >> one of the
>> other DEC fellows. Perhaps they might at least know something
about >> which
>> hardware and operating system(s) supported RTEM?
I definitely remember (and probably still have
some mail
somewhere) > from Megan mentioning that she used RTEM-11 for RT-11
work, running on > RSX machines. Possibly even an 11/74.
I don't have enough information about RSX to know if RTEM-11 was
supported.
However, ...
I'm telling you that it is. Just google for it, and you will find the
documentation from DEC that is still on the net about this product.
It's actually really simple. Go to "www.google.com". Type in "rtem-11
rsx" in the search field, and hit enter.
The first hit will be
http://www.google.se/url?sa=t&source=web&cd=1&ved=0CBcQFjAA&…CjH9ifJeDiJ9sf_daeyGX9-A,
which is "RSX-11M Optional Software Cross Reference Table", which
lists what version of various software is compatible with RSX-11M V4.0
and V4.1. Among these, you'll find RTEM-11 V1.0 and V1.1. More
"supported" than that is hard to get.
Thank you for the reference. Although this does make my goal of having
the code
support running the program under the RTEM-11 RTS even more difficult.
On the
other hand, I doubt that anyone will be likely to even test the RTEM-11
handling
portion of the code, so I am probably going to just assume that what
works for the
RT-11 RTS system under RSTS/E will also suffice for the RTEM-11 RTS under
RSX-11.
>> In
addition, RSTS/E also supported RT-11 programs via the
SWITCH RT11
>> capability. However, only the RT-11 EMTs which are used by a SJ
are >> supported
>> by RSTS/E. At least there is quite reasonable documentation as
well >> as the ability
>> to test and actually run RT-11 programs under RSTS/E up to the
latest >> versions
>> of RSTS/E. RT-11 EMTs for mapped RT-11 monitors (RT11XM) are
not >> supported
>> not are multi-terminal EMTs. Also, probably the latest RT-11
EMTs >> for file status
>> information are also not supported under RSTS/E.
The correct technical term is that RSTS/E have a
RT-11 *run time >
system*. An RTS in RSTS/E provides an environment under which
you
can > get a specific behaviour. So you had RTSes for RT-11, RSX,
BASIC+, > TECO, DCL and some other stuff. Some RTSes were also KBMs
(keyboard > monitors), meaning you could "switch" to them, and get
an interactive > command line interpreter with that. But the RTS
mostly implemented > system calls. However, there were RTSes which
didn't implement any > system calls, and only gave you the basic
calls RSTS/E itself > provided, and mostly focused on being a KBM,
such as DCL.
I apologize for my lack of familiarity with the terminology. Your
description
is what I was attempting to say.
:-)
Actually, my testing seems to show that RSTS/E
supports being able to
run RT-11 programs even if the RT-11 RTS is not activated. For example:
RUN MACRO
is possible if the RTS is normal RSTS/E or RT-11. This might be
based on the
file type. RSTS/E may determine that MACRO.SAV is an RT-11 program and
support the RT-11 EMT requests. Or RSTS/E may support naked RT-11 EMT
requests from any program. That is something I should test.
No, you are confusing things, and making wild guesses.
What do you mean by "activated"? There is no activation. If an RTS is
installed, it will always be used for programs that are marked as
requiring that RTS. This is an "attribute" of a file. Whenever that
file is run, it is run under the indicated RTS. If you try to run a
program that requires an RTS that don't exist I would suspect that
you'll get an error.
That is what I had assumed, however, I am curious how RSTS/E decides
which RTS to use - or none at all as the case might be.
Also, if you type "RUN MACRO", how do you
know that you are even
running the RT-11 version? RSTS/E normally also have an RSX RTS
available, and an MACRO.TSK, which is MACRO-11 running under the RSX RTS.
When MACRO.SAV is run (under the RSTS/E RTS or any other RTS or under
any other operating system including RT-11 and TSX-Plus, it is simple to
just
type <RETURN> at the "*" prompt to obtain the version number and so
identify
which program is being run.
There is no RSTS/E RTS, by the way.
All exeutable files have an RTS associated with it,
and when the >
program is run, it is run under that RTS, which then handles all
EMTs > and so on when the program executes them.
Does the file type trigger the use of that RTS?
Unless my memory have totally rotted away, the answer is no. The RTS
associated with a file is an attribute of the file, just like file
protection. There is a switch to PIP that you can use to check, and
set, the RTS.
That said, all RTS have a default file extension as well, and I think
that is used to search for runnable files if you just type "RUN MACRO"
for example.
That answer helps quite a bit. Thank you!
I do have a
question. With V7 of RSTS/E, the FIT program is able to
copy files from a drive with an RT-11 file structure (such as an RX02)
to the RSTS/E file structure. My initial testing with V10.1 of RSTS/E
shows that (at the very least the distribution which I am using) does
not
have a FIT program. Is there some other method of making a copy of
a file on an RX02 with an RT-11 file structure to a device with a RSTS/E
file structure?
Either FIT, or some "new" program that does the same thing, I'd guess.
I'm no expert on RSTS/E, and my experience is old. I mostly ran RSTS/E
between V7.1 and V9.0, with the majority of my time in the V7-V8
timeframe.
Well, I am having difficulty finding the "new" program under V10.1 of
RSTS/E.
I finally managed to figure out how to MOUNT the RL02 drives I am "using"
(don't forget that all the code is being run under SIMH or E11) under V7 of
RSTS/E when I am running V10.1 of RSTS/E. Since FIT had already copied
to file to the RL02 drives, I could then used PIP to copy the program in
I am
testing to the correct [PPN] on the DU0: drive which is being "used" to run
V10.1 of RSTS/E. A bit inconvenient, but fortunately faster than on a DEC
system.
Also, is it
possible to run an RT-11 program under a DEBUG mode? It
would be much easier to check out the code if that is possible. At the
moment, I can check most of the code under RT-11. However, the
portion which runs in a different manner under RSTS/E as opposed to
RT-11 since RSTS/E does not support all RT-11 EMT requests in the
same manner as RT-11.
What do you mean by "debug" mode???
I am not sure if RSX-11 has an SD(X).SYS device driver like RT-11 which
handles the BPT instructions placed in a program running under RT-11 when
the user wants to stop a program in the middle of running and check out the
code. The SD(X).SYS device driver under RT-11 supports the features that
the ODT subroutine handles without the requirement for that subroutine to be
part of the program which is being tested. Under TSX-Plus, there is a
so-called
debug option which invokes the same sort of support. Since the SD(X).SYS
is written as a device driver in RT-11 (starting with around V5.4 of
RT-11 if
I remember correctly), debugging a program under RT-11 became much easier
since ODT was no longer inserted into the program being tested.
I was hoping that RSTS/E has the same sort of feature available, but
that does
not seem to be the case. But then how did users debug their programs under
RSTS/E?
Jerome Fine