Jerome H. Fine jhfinedp3k at compsys.to
Tue Jul 20 08:13:07 CDT 2010

 >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.
> 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&url=http%3A%2F%2Fwww.bitsavers.org%2Fpdf%2Fdec%2Fpdp11%2Frsx11%2FRSX11M_V4.1_Apr83%2F1_Introduction%2FAA-M778J-TC_optSwXref_Jun83.pdf&ei=kNpETPb-BtqIOKXjtTc&usg=AFQjCNFv-lCjH9ifJeDiJ9sf_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 
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

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

>> 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 
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

Jerome Fine

More information about the cctech mailing list