" To summarize: A directory block consists of a 8-byte Count field, a 8-byte key field and a 256-byte data field."

Dear all,

?

Let’s go back to the 60s where the CKD DASD Devices were developed. At that time a lot of constraints existed, especially concerning main storage. Supervisor functions had to work in a couple of hundred bytes, no space was available to read blocks of 4K or even more into storage.

Concerning PDS Files the directory was designed with 256 data byte and a key of 8 bytes containing the key of the last entry in the block. (Note that a directory is always in alphabetical order. New members are ‘stowed’ in the corresponding place). Key and data area headed by a count field of 8 bytes with CCHHRKLL where K is key length and LL the data length. To summarize: A directory block consists of a 8-byte Count field, a 8-byte key field and a 256-byte data field.

?

Now jump into a simplified channel program to locate the correct directory block:

CCW 1: Search key equal or high

CCW 2: TIC *-8

CCW 3: Read Data

?

The first command compares the key given by the program with the key read from disk, if the key from disk is lower, the channel continues with the next command which is a branch back to the first command (TIC = Transfer in channel). But if the key is equal or high the channel skips the next command and executes the third command to read the data.

Now this all happens in real time while the read head ‘travels’ over the CKD fields on the disk. The channels electronics takes some microseconds to take this decision after receiving the key. Keep in mind that the read head is now just behind the key area. To give the channel a chance to react accordingly a space is necessary between key and data so that when CCW 3 is sent to the device the read head is still before the data field so that the data can be read in.

With this simple channel program and multitrack operation, it’s possible to search for the correct block in a PDS directory who has the size of one cylinder with one channel program.

?

So the “gaps” between the CKD field had to be big enough for slowest CPU where the Disk Model was supposed to be attachable.

?

Bottom line: The shorter you make the blocks and if maybe you add keys the less data can be

stored on a track due to this ‘gaps’ that were necessary with this design and constraints.

?

Best,

Silvio

?

?

?

?

?

From: [email protected] <[email protected]> On Behalf Of Andre via
Sent: Monday, 4 November 2024 12:55
To: [email protected]
Subject: Re: [H390-MVS] Understanding PDS in MVS 3.8

?

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...

Best wishes,

Andre