18 Mar
2010
18 Mar
'10
8:31 p.m.
At 1:41 PM -0500 3/18/10, Jerome H. Fine wrote:
Well, under RSTS it's a little different. Under the hood, things are
set up so that CREF is chained to (and, e.g., MACRO returned to,
though CREF is not limited to talking to MACRO) when they exist in
the system ($) account. The $ account can span multiple physical
disks. Programs don't need to [explicitly] know about it, the OS
finds it for them. However $ maps to a single [PPN].
So I don't see this as a limitation. If MACRO and CREF are installed
normally, everything works as it's supposed to. The real
"limitation" that I am aware of is that you can't have MACRO chain to
a private version of CREF. Say you're working on a development
version of CREF. You need to write your own harness to exercise it;
you can't use the system version of MACRO, FOR, etc., to do that.
From the perspective of a (former) system manager, it's not a
problem. Remember, this is a multi-user timesharing system. Quite a
bit different from the RT audience.
John A. Dundas
III wrote:
Not sure why you need to change what MACRO/CREF are already doing;
they work as is under RSTS. If you're fixing a Y2k bug the file
chaining code, and for that matter the rest as well, works just as
well under RSTS as it does under RT. I would think the best
approach is not to change anything, unless it specifically
addresses a bug.
From my testing of MACRO / CREF under RT-11, there
are 3 separate
problems, in addition to
the lack of the 4 digit year when DEC added support for the
years after 1999:
(a) The DEC version of the MACRO / CREF pair can ONLY be located on
the SY: device
since the .Chain EMT request is hard coded to transfer control
back and forth to each
other using only files on the device SY:. No other utility
program has that restriction.
Note that this problem exists on all three operating systems:
RSTS/E, TSX-PLUS and
RT-11. (b) Under RT-11, when running under a mapped operating
system, if
VBGEXE is used under
There is no concept of VBGEXE under RSTS. MACRO can be used to
compile multiple files, in separate compiles (I think that's what
you're getting at), without reloading. Either way, again, this is
not a problem for a timesharing system. Multiple instances can be
running simultaneously, without problem.
(c) Under RT-11, when running MACRO.SAV as a system
job, VBGEXE is required to
load into extended memory (64K in size) and initiate MACRO.SAV;
however, if a
cross-reference table is requested, the .Chain EMT will cause
the job to abort with
the complete loss of the listing file.
A non-issue with RSTS.
As it happens, according to the PDF that you suggested
that I look
at, the .SaveStatus
EMT request under RSTS/E returns the device name of the file in
question - as opposed
to the RT-11 values which are totally different. However, since
there is no specific mention
of the .CStatus EMT request in the PDF as to what happens if used
under RSTS/E (the
most probable result is that the .CStatus EMT request will be
ignored under RSTS/E), then
program control will be used to solve if RSTS/E is being used vs
RT-11 when MACRO.SAV
is found to be executing under an unmapped monitor. This is because
the third word of the
data block returned by RSTS/E for the .SaveStatus EMT request will
be 6544 decimal
(RAD50 "RO" = 12620 octal = 4096+2048+384+16) which is very
different from the size
of MACRO.SAV (about 100 blocks) which is the value found in the
third word under
RT-11,. I found this information in the PDF on pages 6-10 and 7-57.
I'm not following where there is a problem, but OK.
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.
A review of the source code for an older version of the emulator
suggests that the 50/60Hz bit (5) is always set to 0. Oh well.
There is one other discrepancy between the documentation and the
source: evidently bit 15 (system clock presence) DOES get set,
always, contrary to what is written in the manual.
John