Johnny Billquist wrote:
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.
I agree. I forget to use the correct terminology. If you can indulge me
now that I have turned 72 years old, that would be appreciated.
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)
Well, since we both agree that it is extremely unlikely that RTEM-11 will
ever be used, ...
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?
The last I heard, Megan was looking for work in the medical care field.
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...
Obviously, but it is difficult to test a program when I can't even "RUN"
it.
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.
The work around that I use is to MOUNT DL0: which already has
the files (Having been copied by FIT from DY0: to DL0:).
If anyone else is reading this, can you suggest anything?
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).
Actually, for VMS systems, if my faulty memory is able to remember
correctly, the
compiler builds symbol tables outside of the code and data in a manner which
does not impact at all on the program when debugging is NOT taking place.
I had a project under VMS on a VAX about 20 years ago to look at those
tables and provide trace-back information to the user when a program crashed
that was running detached, i.e. without a terminal to send the message to.
From what I remember, the FORTRAN compiler set up the symbol tables for
debugging so that there was no impact on the code when debugging was not
active.
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.
Under RT-11, the SD(X).SYS device driver traps the BPT instruction when
it is executed no matter what state the hardware is in. Of course, this
also
STOPS ALL other code from executing as well. This is not considered a
problem under RT-11.
Under TSX-Plus, the debugger STOPS only the code for that job on that
terminal from running. There is also a separate debugger for the TSX-Plus
operating system which does stop everything in the system.
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?
Actually, no! A symbol table is allowed, but I normally never use one
since the listing of the program has always been sufficient. Also, if the
code is already loaded into a known location in memory (e.g. the RT-11
Resident Monitor), it is possible to place a BPT in the desired instruction.
As for a program, I usually use SIPP to place one or more BPTs in the
code, so you are correct in that regard. Some device drivers under
RT-11 include code to request a BPT to be placed in the code via
a SET command.
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.
AGREED!!
Jerome Fine