开云体育

On Monday, November 18, 2024, 4:32 AM, Joe Monk via groups.io <joemonk64@...> wrote:

Everyone,

Also, please remember that the CKD format on 3390 DASD is emulated. The actual format of the DASD is in cells, so there is some wastage trying to make?the CKD format work, with there being 1729 cells per track.

Second, they are using?a 27920 block size on a 3390. According to the book, that is only 98.8 percent space efficient.

By my calc, with a max blocksize?of 56664, divided by 80, yields 708 records per track, dividing for half-track blocking would give 354 records per half-track, for a max efficiency?blocksize of 28320.

So it seems to me to be working as designed.

Joe

On Mon, Nov 18, 2024 at 3:42?AM Greg Price via <procegrog=[email protected]> wrote:

On 4/11/2024 10:55 pm, Andre via wrote:

It is not that easy to see what Sergio is asking about, so i made a visualization.

When PDS has only one member with size of one track, oddly enough there is some space left at the end.

What its purpose remains unknown...

If, in the above picture, the white space is supposed to represent that part of the track that cannot be used to hold any accessible "thing" then the above picture is not accurate.

The white space should be distributed into several locations instead if being lumped into one area at the end.

Some places where I think the white space should be are:

• the space between the track's record zero ("R0") and the directory block's key.
• the space between the directory block's key and the directory block's data - which gives the electronics the time (as the disk rotates) to decide if the key value means that the block's data should be read or not.
• the space between the the directory block and the EOF marker.
• the space between the EOF marker and the member's first data block.
• the space between the member's first data block and the member's second data block.

And in the points above I neglected the Count field of each physical record, so there are even more gaps that I describe.

You can use the LISTDS or LISTD command with the LABEL operand to show a data set's VTOC entry.

The DS1TRBAL field shows the unused byte balance for the last track of the data set containing data (for sequential and partitioned data sets).

The access method will look at the DS1TRBAL field to decide if a block of a given size will fit on that track or needs to go to the next track.

listd trk1 la?????????????????????????????????????????????????????????? ?
GREG.TRK1.CNTL????????????????????????????????????????????????????????? ?
--RECFM-LRECL-BLKSIZE-DSORG???????????????????????????????????????????? ?
? FB??? 80??? 27920?? PO??????????????????????????????????????????????? ?
--VOLUMES--???????????????????????????????????????????????????????????? ?
? TSO003??????????????????????????????????????????????????????????????? ?
--FORMAT 1 DSCB--?????????????????????????????????????????????????????? ?
F1 C3C2E3E4F0F3 0001 7C0143 000000 01 37 00 C9C2D4D6E2E5E2F24040404040? ?
7C014300000000 0200 90 00 6D10 0050 00 0000 82 80000000 000005 0044 0000 
01000556000E0556000E 00000000000000000000 00000000000000000000 0000000000

So after performing the test procedure under discussion, the LISTD of the subject PDS is shown above.

As previously discussed, 668 records could not be saved on the first track, but 667 records could.

DS1LSTAR is 000005 as expected because 5 records were written to the track, those being:

1. The directory block.
2. The directory EOF.
3. The member's first block.
4. The member's second block.
5. The member's EOF.

DS1TRBAL is 0044 which equals 68 decimal.? You can't fit another 80-byte record in 68 bytes of space.

As previously mentioned, the gaps (of a sufficient angular size to provide sufficiently long (for the expected disk rotation speed) for electronics to react to the discovered situation) are essential in the CKD paradigm.? When CKD/ECKD DASD are emulated, how the data is stored by the emulation scheme is arbitrary.

Cheers,
Greg