21 Mar
2010
21 Mar
'10
12:16 p.m.
John A. Dundas III wrote:
At 10:38 AM
-0500 3/19/10, Jerome H. Fine wrote:
I am confused by some of your response to (b) and
(c). Are you
suggesting that
because there are problems which occur in RT-11, but not in RSTS/E,
the problems
which occur in RT-11 should not be fixed?
Definitely not. I am trying to point out where things that might be a
problem in RT are not necessarily a problem in RSTS, though. My goal is to
provide a common utility which functions correctly
under all OSs,
not just RSTS/E or RT-11. TSX-PLUS has different issues as well. I can
add code which solves the problems for RT-11, but since RSTS/E will
likely
be impacted, a few additional lines can prevent any impact on
RSTS/E. As
most programmers realize, when any changes are being made to a program,
the additional effort of fixing other problems is much less than if
done in a
separate operation.
Maybe. My approach would be to strictly limit (minimize) the amount
of change to that which is absolutely necessary to correct the defect,
thus minimizing the possibility of unintended consequences. I don't
know that that's necessarily different from your approach, maybe just
a different way of stating it. Still, even if
a few extra lines of code are required for the
transfer of control back and forth
via the .Chain command between MACRO and CREF as the contents of a
command file
are processed when one or both of MACRO or CREF are not on the SY:
device, I can't
see that as a huge problem based on the flexibility that provides.
All I'm saying is that this already works correctly under RSTS.
Caution should be exercised to not break what already works. I know
you're cautious. By the way, I
can't think of any other program that uses CREF except
MACRO? Do
you know of any?
Sure. Could the linker and Fortran compilers could optionally use
it? [My memory is a bit hazy.] Other compilers did use it: BP2 [see
the /CROSS_REFERENCE switch], Pascal?, C [see the /CR switch], Cobol
[see the /CROSS_REFERENCE switch], and maybe other compilers used it
as well. I know many user-written utilities, including some of my
own, used it as it was a well documented interface. What I still
don't know is how RSTS handles the .CStatus RT-11 EMT
request.
Would you be able to run a small test program under RSTS for me to
determine
that question. Or is there a downloadable RSTS image available that
can run
RSTS under SIMH available that I can use to test it myself?
Yes. See the SIMH software site:
<http://simh.trailing-edge.com/software.html> There is also
a final question about the information in the PDF on
page 6-16 which states
that bit 5 of offset 300 will always be zero. Are there no RSTS/E
systems running where
the power is 50 Hz rather than 60 Hz? Unless this omission has
been corrected, but the
documentation has not been updated? Otherwise, the TIME printed on
the listing from
MACRO.SAV will be incorrect if run under a 50 Hz system. Likewise
for other programs
which check bit 5 in offset 300 (the .GVal EMT request) and attempt
to convert ticks to
the time.
Yes, RSTS runs on 50Hz systems, no problem, though I've never
personally done it. All I know is that RSTS attempts to present the
time value in a format RT expects (as it keeps time different
internally from RT). Maybe the ticks value IS wrong. Is it every
displayed? I just don't remember whether MACRO uses that in its
listings or not. Otherwise, the
time of day at the top of each page in the listing
would be
noticeably less than the correct time near the end of the day, i.e.
too few ticks
would be calculated.
No. The .GTIM value is recomputed each time it is requested. The
emulator performs a .DATE request to RSTS and then converts the values
into RT-11-expected quantities each time it is called. IF there is a
conversion error, it is more or less constant. Please let me
know if you can run a small RT-11 program under RSTS to
print the contents of the information provided by the .CStatus EMT
request?
You can perform this yourself with the software referenced above. According to the code .CSTATUS merely returns
immediately to the
calling program without doing anything.
I will make that assumption then since it seems like the correct solution.
However, you do not mention if the CARRY bit is clear indicating no
error or set indicating an error. I would tend to assume at least the
latter since otherwise the user would attempt to use data that could
cause a serious problem. Can you check the question of the CARRY
bit status on return from RSTS for the .CStatus EMT request?
Hope this helps,
This all helps quite a bit. In fact, without the PDF and your suggestions,
I probably would not have been able to justify to myself, let alone others,
the reasons for all of the extra code. THANK YOU!!!!!!!!!
It seems like you have access to the source code for the RT11 Run Time
system under RSTS? Is that the situation?
Also, I have a few older V9.0 RSTS and Micro-RSTS manuals from around
1985 that I will likely toss within a year. How can I get them to you
so they
can be scanned? I also have a number of RT-11 manuals of V04.00 and
early V05.00 and V05.01 manuals. Also I believe a full set of V05.05 of
RT-11. Since your site has so many different versions of RSTS and RT-11
which are incomplete for most versions less than the latest distributions, I
thought that the manuals may be interesting to you.
Also, are you aware of anyone else who is still active in writing bug
fixes and
enhancements for RT-11? If anyone else actually is active, I have not found
them at this point.
Jerome Fine