In a message dated 6/17/2006 4:39:03 A.M. Central Daylight Time, [EMAIL PROTECTED] writes:
>That doesn't look right, but please consider my bad memory. But wasn't the >track capacity for a 3380 - 47476??? You start with the total number of bytes on the track, called "track length' in the device geometry charts (e.g., 3990 or 2105 control unit reference book). A 3380 has a track length of 47968 (in Lynn Wheeler's formula below), and a 3390 has a track length of 58786. Then subtract all the following: how many bytes are used for the first gap between index point and the beginning of the home address, how many bytes it takes to store the full home address on the track, how many bytes are used for the next gap after the home address and before the R0 count field, how many bytes it takes to store a count field on the track, and how many bytes are used for the next gap after the count field. If you want to, you can use all these bytes for an R0 with a really big data field and/or even with a 255-byte key. This is very seriously contraindicated and not recommended. It is much better to let standard access methods build the rest of the track, in which case you must also subtract all the following: how many bytes it takes to store an 8-byte data field (standard R0 has no key and an 8-byte data field), how many bytes are used for a gap between the end of R0's data field and the beginning of the first "real user" record's count field, how many bytes it takes to store a count field on the track, and how many bytes are used for the gap after a count field. This yields a somewhat smaller number, called variously the size of the largest user record on the track, largest R1, or something like that. It is seriously recommended that you let standard access methods build this record and call it record number 1, or R1. But if you want to, you can write your own channel program to write this user record and use EXCP or STARTIO to write the record with anything you want in the "record ID' part of the count field. Normally, the record ID will contain the CCHHR of the record, but, since my name is Bill Fairchild, I could put the five characters "BILLF" in the count field of every record I write on the track. Again strongly not recommended. The TRKCACL system service uses all the various device geometry variables to calculate the effective size of a record with a given key length and a given data length as it would require when stored on a track. This number must be subtracted from the total remaining user-usable bytes on the track, called track balance. If the remainder is non-negative, the record will fit on the track. Charts that tell how many records of a given size will fit on a track use this process and assume that all records have the same key length and data length. To make matters worse, you can't simply use your data length in computing how many bytes are needed to store that data field on the track, as data is no longer stored byte-for-byte on tracks. In the early days of S/360 DASD it was, but ever since the 3330 (I think, but I could be wrong) data has been written by the control unit not in bytes but in "cells". If the cell length is 32, e.g., a one-byte data field will require 32 bytes on the track to hold one whole cell, of which only one byte is used by the user. Lynn Wheeler's formulae reflect the necessity for such cells. For a 3390, the largest possible user record (R1 data field) with no key is 56664 bytes ( I think). >From an earlier post by Lynn Wheeler: > Track Record Size >Device Capacity Without key With key >3375 36000 224+#(D+191) 224+#(K+191)+#(D+191) >3380 47968 480+#(D+12) 704+#(K+12)+#(D+12) Bill Fairchild ---------------------------------------------------------------------- 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
