🚀 go-pugleaf

On  Mon, 25 May 92 12:10:42 ADT  Regis BOSSUT <RPARBS@FRFUPL11.BITNET>
writes:

> a) Is it somewhere possible to make zero seeks 0ms time consuming, so
> that I am able to transfer data at the 2400 kB/s rate for a single
> cylinder ?

I cannot speak for the VM/CMS environment, however, have you looked
at using Read Multiple count/key/data to read an entire track at time?
If the command were correctly chained from a read record zero with
multi-track on you might be able to read an entire cylinder with a
single channel program.  Of course, in MVS multi-track operations are
not allowed unless the data set is allocated on a cylinder boundary.

Also, I haven't tried this to read cylinders at a time but have used
read multiple to read individual tracks from DASD in single revolutions
and it works OK.  You do have to be prepared to process the count fields
to figure out where the key and data areas are that you have just read.

There is no write multiple, however, it should be possible to chain the
individual writes required to write out an entire track at a time.
Check the chaining requirements on the various write commands (I would
check IBM 3880 Storage Control Models 1,2,3 and 4 Description Manual
GA26-1661 or perhaps a manual for the particular Model that you use.)
Writing a cylinder may be possible, but I haven't done that either.

Of course you will need an initial seek to position the heads to the
cylinder where all this is to happen and appropriate search/tic to
position you to the first block in the starting track that you want
to transfer.  I can't think of any way around that ;-)

> c) The CCW 'Set sector' needs one byte which is different from the
> record number. What is the meaning of this sector number ? Tables for
> sector numbers corresponding to record number can be found in module
> DMSDIP.

Set sector allows the device to disconnect from the channel until the
sector comes under the read/write heads at which point the device
attempts to reconnect to a channel to transfer data.  If all channels by
which the device can transfer data happen to busy when the sector comes
by then the device has to wait an extra revolution to try again (thus
the term RPS miss.)  On older control units and devices, the device
had to reconnect on the same path as the original request, however,
newer configurations allow the device to connect over whichever path
happens to be not busy when the chance comes.  There are well known
"rules of thumb" for how busy channels can be on average before you
begin to suffer from RPS misses.  Of course there is nothing that
requires that your channel program issue a set sector and you will
never have an RPS miss, however, your channel utilization will begin
to look very bad and overall throughput will suffer.  VM may not allow
you this degree of control and potential for abuse, I don't know.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-  J. Anthony Fitzgerald                  Phone:     (506) 453-4573
   Computing Services                     NetNorth:  JAF@UNB.ca
   The University of New Brunswick              or   JAF@UNB
   PO Box 4400
   Fredericton, N.B.  Canada
   E3B 5A3