(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
