Help with running RT-11 SAV files under RSTS/E

[John A. Dundas III]

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.

>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.
>
>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.

>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