19 Mar
2010
19 Mar
'10
4:54 p.m.
At 10:38 AM -0500 3/19/10, Jerome H. Fine wrote:
Based on your explanation and the documentation in the PDF on page 6-16, my
assumption is that RSTS converts all time quantities to ticks based on a 60 Hz
clock. So even if the actual hardware is running at 50 Hz, the
conversion into
ticks to satisfy the .GTim EMT request does so based on a 60 Hz clock.
I can't say that for certain. .GTIM will return a "reasonable" value.
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.
compile. Again, the number of blocks of disk access
involved are too low
to be of concern, so this is not a disagreement.
OK. I'm not trying to disagree, just putting facts out there.
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.
Hope this helps,
John