bqt at softjar.se
Wed Jul 21 06:47:53 CDT 2010
"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
> 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
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
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
> 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
> 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
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.
More information about the cctech