Hi Steve,
Here’s the answer (sort of) from the Ref Manual for a Read operation …
“The read order causes the device controller to initiate an input operation.
Bytes are stores in core memory, in an ascending sequence, beginning at the
location specified by the memory byte address field of the command doubleword.
The Input operation continues until the device signals a channel end – or –
until the byte count is reduced to 0 and no further data chaining is specified.
Channel end occurs when the device has transmitted all information associated
with the input operation and no longer requires the use of IOP facilities for
the operation.”
So … in your example, if data chaining was not specified (DC flag bit set) and
suppress incorrect length was permitted (SIL flag bit set) the I/O operation
would have been completed after 100 bytes were passed.
“If [the SIL flag] is 1, an incorrect length indication is not considered as an
error by the IOP, althout the IOP retains the incorrect length indication and
provides an indicator (bit 8 of the status response for SIO, HIO and TIO) to
the program. If the SIL flag is 0, an incorrect length is considered an error
and the IOP performs as specified by the HTE and IUE flags. Incorrect length
is caused by a channel end condition occurring before the device controller has
received a count-done signal from the IOP [a “shorter” physical record] or is
caused by the device controller receiving a count-done signal before end of
record; e.g., count-done before 80 columns have been read from a card.”
So … the latter situation described in the paragraph above seems to describe
your situation – ask for 100 bytes of input but the physical record is 200
bytes. It sounds like the 100 bytes would be transferred properly and the rest
of that physical record would be unavailable unless data chaining had been
indicated in the original READ command.
I think to actually read the entire physical record, you would have to issue a
“backspace record” (available to tape devices), increase the acceptable record
length and issue another read command. No wonder it’s easier to generate and
incorrect record length message and issue an abend!
I didn’t have to get into this level of detail on a Sigma as I had the benefit
of the operating system’s somewhat higher level CAL1 commands. Hopefully
someone who has dealt at the diagnostic level can chime in!!
I’ve attached a copy of the relevant pages from the ’73 edition of the
reference manual.
* Jim
From: xds-sigma-comp-bounce@xxxxxxxxxxxxx <xds-sigma-comp-bounce@xxxxxxxxxxxxx>
On Behalf Of Steve Martin
Sent: Sunday, March 10, 2024 8:59 AM
To: xds-sigma-comp@xxxxxxxxxxxxx
Subject: [xds-sigma-comp] Any Sigma gurus still hanging around on this list?
Got a question regaring Sigma I/O. (I'm churning through a long-time project of
writing a simulator for Sigma 7 under Linux.)
Say the CPU issues an SIO for input from a tape. The SIO specifies 100 bytes be
read, but the next record to be read on the tape is 200 bytes long. I know that
this could cause a length mismatch status back to the CPU, but what happens to
the extra 100 bytes in the record? Do they get thrown out? Does the IOP or the
CPU buffer them and use them for the next read? Or something else?
Thanks to any who might have the answer.
Attachment:
IO Ops.pdf
Description: Adobe PDF document
