Post by Ronald Tatum
Now, here's the logical conundrum I have when I think about simulated
tape I/O: The 3420 (and its predecessors, don't know about successors) only
returned "EOT reflective marker encountered last operation" status on a
"write-type" operation - never on a "read-type" operation. Thus, the program
writing data to a tape was supposed to recognize that hardware condition and
immediately write two end-of-file marks on the tape and do whatever was
supposed to be done about an end-of-physical-reel condition for its
purposes. Any program that read tapes was supposed to recognize that two
EOFs in a row *usually* signified end-of-data on the tape reel. The hardware
wouldn't "tell" the reading program that it was about to get into real
physical trouble. If the *writing* program didn't follow that convention, of
course, bad things happened - the tape was ripped off the supply reel and
operators got mad, etc., etc. So, since there is no symmetry between
reading and writing on a tape, and in any case the hardware never knew nor
cared how much data was on a tape (or could be), just that someone tried to
write beyond the EOT reflective marker, how *should* one simulate operations
on a "virtual" tape on a "virtual" machine simulating the real thing? I
really don't have any suggestions - all the schemes I thnk of I can
immediately object to; I guess I had bad early life training ;-).
I can't vouch for the EOT being ignored on read (but it was certainly possible
to wind the tape off the wrong end).
On OS, the processing you says "should be done by the program" is in fact done
by the access method software. When it recognises the EOT marker, it invokes EOV
processing (SVC X'37', who could forget the x37 abends?).
There should be enough space after the EOT marker to write tape labels and two
While there are (slightly) different EOF and EOV labels, what happens at EOV
depends on the JCL. OS would request another scratch (output) subject to any
limit specified in JCL, or the next input.
In the case that Hercules is writing to real tapes, it should emulate (as far as
possible) real mainframe tape behaviour, but I see no need to be concerned with
the capacity of any theoretical 2400 foot tape.
For TDF-style tape, I think we need a new format. The current style is
equivalent to mounting a tape without a WER. The new format should allow users
to specify the presumed tape capacity after which Hercules would
a) Pretend to find an EOT
b) Pretend the tape came off the spool.
Presumably any program that cannot handle that would have equivalent problems on
I don't think we need to allow for IRGs, but others may disagree. Perhaps all we
need is for the new-style TDF to begin
where the capacity is either a number of feet to which some calculation is
applied, or a number of megabytes.
This second TDF format would need to be written to by Hercules, and may need
state information to allow it to track rewinds and other tape operations.
Microsoft's most solid OS: http://www.geocities.com/rcwoolley/
Note: mail delivered to me is deemed to be intended for me, for my disposition.
If you don't like being told you're wrong,
------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get 128 Bit SSL Encryption!