"Jerome H. Fine" <jhfinedp3k at compsys.to> wrote:
Johnny
Billquist wrote:
> >> 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).
>
> Yes. And RTEM-11 will also behave slightly differently that vanilla
> RT-11 for some of those calls. And assuming there is a product called
> RTEM, which runs under VMS, it too will behave differently than RT-11.
> However, RTEM-11 and this RTEM will not necessarily behave the same
> way, since RTEM-11 and RTEM are different products, and different
> implementations, written by different people (assumingly) at different
> times.
Agreed! The problem is that I have been unable to locate any
documentation for which RT-11 EMT requests are handled by
the RTEM-11 RTS along with the differences between RT-11
and the RTEM-11 RTS.
*sigh* Still not an RTS... RTEM-11 is a program, not an RTS. There is no
RTS concept in RSX.
The RSTS/E RTS system for RT-11 EMT requests is fairly
well
documented in the RSTS/E documentation. The only areas which
are a bit hazy is when the [PPN] (at offset zero in the Common
Area) is not specified (left at zero). If the [PPN] is included, then
it is used correctly along with the file name that is specified.
But for RTEM-11, I don't have any documentation at all.
The obvious answer is that this is documented in the manual that came
with RTEM-11. Now, you just need to find someone who has it... (not me)
> RTEM-11
is not an RTS. RTEM-11 is a product that ran (runs) under RSX.
> If I were to make a qualified guess, I'd suspect that RTEM-11 is a
> program that you start just like any other program under RSX. That
> program then looks like an RT-11 environment, so you can run RT-11
> programs inside that.
> RTEM-11 will catch EMTs and other traps, and do something appropriate
> to those traps. It's not difficult to catch traps in an RSX program.
> Exactly what it does, and how, is another issue. And that is something
> you are asking about, and which I cannot answer, and it seems noone
> else can either, since noone around here have RTEM-11, or have used
> it. As I said, I think Megan mentioned that she had used it, but she's
> the only one I know of who have admitted to any knowledge about this
> product.
I suspect that Megan is no longer available for help.
I have not seen or heard from her for a long time. You know anything?
> >>
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.
>
> Not an RTS, but anyway, you are most probably very correct in the
> assumption that no one will test you code under RTEM-11.
That should make the situation fairly simple. I will ask anyone who
actually
does run under RTEM-11 to contact me if it does not work. Since I will
be 72 years old in a few days, and I doubt that the code will be finished
very soon, they won't have many years to check in.
Do that. I very much doubt you'll get any response though.
> >>
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.
>
> Are you not reading what I am writing?
> This is an attribute of the file. You *tell* which RTS a program
> should run under. Normally you do not need to do this explicitly,
> since every file always have an RTS associated with it, and it's
> normally already correct, so no need to change it.
I have access to both V7 and V10.1 or RSTS/E. However, I have not found the
program in V10.1 which copies files from RT-11 files structures to
RSTS/E file
structures.
And this has just about nothing to do with the question on how RSTS/E
determines which RTS a program runs under, but anyway...
As I've said before, I know about FIT. If DEC replaced FIT with
something else in RSTS/E V10, then you just have to search around in the
system. Look at the help files. That's usually a good place to start
searching. Read the manuals. I think the V10 manuals are online
somewhere as well.
I don't have any better answer off my head, and I am not going to
install RSTS/E to figure this out for you. You can do the work yourself.
It shouldn't be hard.
But by now it should be obvious that no one around here is offering the
answer so you'll have to figure it out yourself.
Under V7, RSTS/E has a program named FIT which I use
to copy
a program from an RX02 device to an RL02 device. Based on your description,
FIT must attach the RT-11 attribute to the file during the copy.
Yes, it's a fairly good assumption that FIT will create all copied files
from an RT-11 formatted disk on the RSTS/E system
assigned to the RT11
RTS. Assigning any other RTS to the files would probably be a
mistake,
since the files most probably are coming from an RT11 system.
It would be appreciated if you could confirm that I
finally have it
correct.
If you mean the guess that FIT would copy the files and assign them to
the RT11 RTS, then yes. That is most likely correct. It might even be
that FIT is an RT11 program itself as well...
> >>
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.
>
> That sentence makes no sense. Either you are running RSTS/E V7, or
> RSTS/E V10, you cannot run RSTS/E V10 when you are running RSTS/E V7,
> or vice versa. You'll have to reboot the machine in order to run
> another version of RSTS/E.
AGREED!! When I tested the program under V10.1 of RSTS/E, the only
way I managed to copy the program after booting V10.1 of RSTS/E on the
DU0: device was to MOUNTed the RL02 device which had the program I
wanted to test. The RL02 device had previously been booted to V7 of RSTS/E
and FIT had been used to copy the program from the RX02 device to the RL02
device.
So YES, two boots were required, the first to copy the program from the RX02
device (with an RT-11 file structure) to the RL02 with a RSTS/E file
structure
using FIT under V7 of RSTS/E. Then I SHUTUP V7 of RSTS/E, booted the
DU0: device which has V10.1 of RSTS/E, MOUNTed the RL02 and copied
the program from the RL02 to the DU0: device. Since this will not be done
except for testing, it is acceptable.
Aha. So what you actually are saying is that you booted RSTS/E V7,
copied the files from an RT11 formatted disk into the RSTS/E system. You
then booted RSTS/E V10, and accessed the files previously copied.
Yes, that would work just fine.
> With ODT
linked in to the program, just as you mentioned that people
> normally did with RT11 in the past as well.
>
> The same type of development cycle is still what people use to this
> day. You build a special debug version, which you run through the
> debugger, and when you are happy, you build a new, leaner version,
> without debug support.
I agree that this was also done in the past with RT-11.
And is still done to this day in RSTS/E and RSX. And while exactly the
same, something similar is done in Unix systems, Windows systems, VMS
systems, and any other system I can think of.
The reason being that for debugging you don't want a compiler to
optimize things, and you want to include symbol tables in the compiled
image for debugging purposes, while you do not want that stuff for the
finished program, since it takes space and makes the program slower
(symbol table and non-optimization).
Modern systems however, usually allows the debugger to be dynamically
attached to a running program so you don't have to include that bit
already at the link stage.
> I'm
not sure how you use that device driver under RT11, nor how useful
> it actually is...
However, by V05.04 of RT-11, DEC developed the SD(X).SYS device
driver which allowed a program to have a BPT instruction without the
requirement to include ODT as part of the code. If the user LOADed
SDX.SYS prior to executing the program with the BPT, but without
ODT included, the code in SDX.SYS initialized the required VECTOR
to trap the BPT instruction when SDX.SYS was LOADed. The code
in SDX.SYS then performed all of the functions that ODT supported
(and a few others as well) without adding any extra code to the program
being tested. It is even possible to place a BPT in the monitor code
and test those instructions as well.
Ok. So, no symbol table stuff, and no possibility to add breakpoints,
watchpoints and other stuff in the program until you hit atleast one BPT
in the code which cause the code in SDX to be called?
Based on some of the comments in the SDX.SYS source
file, it looks
like it is also available under both RSTS/E and RSX-11. However,
since I have almost no knowledge of RSTS/E and even less of RSX-11,
I can't even begin to speculate why those comments are in the source
file.
I dare say that it would be impossible to do the same in RSTS/E or RSX.
The reason is that the BPT vector that the CPU uses is set up by the
operating system, and is always used. Any program running does not use
that vector, but has a dynamically installed debug vector defined as a
part of the system image, or set up by a system call by the running
program. You do not, and can not, access the hardware related things
directly in RSX or RSTS/E and hope that anything will contiue to work.
The hardware BPT vector is used by the executive debugger in RSX (XTD),
which is a OS debugger somewhat similar to ODT, but specifically
designed to debug the OS. It is always there, and if you mess with that,
you are going to be sorry. When a user program executes a BPT
instruction, the kernel gets called. It checks wether the program have
installed a debug handler, and if so, that handler is being called in
the context of the user program. If no debug handler have been installed
for that program, the program aborts. You can have any number of
programs running in parallel, all with their own installed debug
handlers, which can actually be different debuggers that have nothing to
do with each other. How on earth do you think a common device driver
could ever handle such a situation?
RT11 is a single user system, where the OS do so much less for you that
this concept is even possible. For more complex systems, you cannot do
things this way.
Johnny