(IBM Mainframe Discussion List) wrote:
Careful reading of the 2105 Command Reference doc shows that valid sector
numbers are not documented as being ignored. I take that to mean they are used
as documented; i.e., the next action on the track will commence with track
orientation at a predictable position on the track. If the next action is to
find a given record ID, then the search must begin at that point and nowhere
else on the track. For this reason alone a valid non-X'FF' sector number
cannot be ignored.
My understanding has been that an entire track is staged when any record
on the track is accessed. Record accesses are then satisfied from the
staging area. (Does that processing occur only for the virtualized
tracks on STK "Iceberg"?) If it were my code, I would build an
in-storage index of all count fields while staging the track. That way I
would never have to do any kind of lengthy search through the data. And
RPS data would be meaningless to me ... I think ...
Consider the example of a track containing eight records whose record IDs
are all BILL1. There is no control unit microcode requirement that a record
ID, commonly called CCHHR, contain the CCHHR where that record is stored on the
track. Standard IBM access methods assume, create, and enforce this
condition, but non-standard use of DASD can create this situation. Each of the 8
records whose IDs are all BILL1 can be unique; i.e., they contain different
data and can even be of differing lengths, some with and others without key
fields of differing lengths. The sector number must be used in a case like this
to find the correct record.
Interesting point. I had not thought of the problem created by duplicate
identifiers.
I didn't say that this kind of track is a good idea. But the hardware has
always allowed it and non-standard software can still be used to access it.
There are several other examples of control information that are now
specifically documented as being ignored on an ESS (caching algorithm bits, e.g.).
If the ESS ignores a valid sector number, then the documentation is
deficient. John Gilmore is quite correct that an invalid sector number must be
diagnosed. If software has put an invalid sector number into the channel program,
the rest of that program should be suspect as well. Perhaps sector numbers
will evolve away in a future technology that also no longer employs cylinder
and track numbers.
I would still like to know definitively whether coding a sector number
of x'FF' will have a deleterious effect on I/O performance. Put another
way, assuming more or less "standard" formatting of record identifiers,
will a sector number of x'FF' yield identical performance to a
calculated sector number?
In the absence of any documentation or definitive statement to the
contrary, I guess we'll keep using the calculated values.
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
