On 24 January 2018 at 17:59, Ron hawkins <ronjhawk...@sbcglobal.net> wrote:
> Tony,
>
> I am way in over my head here, and I am sure I will use the wrong terminology.
Not to worry. I'm sure I've got things wrong too. And the old memory
isn't what it once was...
> As I remember it RPS was implemented by passing seek and set sector to the
> DASD together so there was only one disconnect sequence? Without RPS there
> was a disconnect/reconnect sequence for the seek, followed by set sector.
On any disk you can write a channel program that reads a record in one
go. You would chain together a Seek CCW to position the heads to the
right cylinder (and set the track number at the same time), a search
CCW to find your record by its number or key, a TIC ("branch) CCW to
loop back to the Search if it fails, and finally a Read CCW to get the
data.
But this is a really bad idea, because the channel is busy from the
start of the seek to the end of the read, and the physical head motion
is very slow compared to the data transfer speed. If you tried to
start another channel program against another device on the same
channel, it would get a Busy from the SIO.
So the traditional pre-RPS channel program has a stand-alone Seek. The
channel passes this to the CU/drive, and the channel program ends with
Channel End but no Device End. Now another device on the same channel
can have a channel program started against it. Then way way later,
when the access arm arrives at the right cylinder on the first drive,
a Device End is delivered. Now you issue that original program I
described, but this time there is no Seek time, and the channel is
busy only during the search loop and data transfer. But that can still
be bad, because your record may have just gone by as your Search CCW
executes the first time, and so the channel will be in a loop running
your search until the record comes around. On average obviously you'll
be half a revolution away from the start of your record.
Enter RPS. The Seek stuff is the same as above. But your channel
program now has a Set Sector CCW chained in before the Search loop,
which tells the device where rotationally it should start looking. The
control unit/device *on their own initiative* disconnect from the
channel, allowing it to be used for another data transfer on another
device. When your record is close to being under the head, the CU
reconnects to the channel, and with luck your Search CCW finds the
record on the very first try. If it's a little too soon, well your
record won't be much further away.
But... The reconnect can miss ("RPS miss") if the channel is too busy
for whatever reason. But the CU/device will retry, so your channel
program doesn't need to do anything.
Where does the sector number come from? Either the program can
calculate it or it can obtain it from when it wrote the record, using
a Read sector CCW chained in to the Write channel program.
> Or something like that. My curiosity is crying out for someone to correct me 😊
Doubtless someone will correct my fuzziness between the CU and the
device here...
Tony H.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
