Andre,
?
Despite what you may think, there are gaps everywhere on the DASD surface.? I dont know what hex dump you are looking at, but it isn't going to show the gaps.? If you are looking at a hex dump generated by Hercules, that is dumped from an emulated DASD.? But be assured that if a real DASD device, such as an actual 3350 or a 3380 device were being used, there would be gaps on every track.
?
There are many areas on each track that are set aside and are part of the overhead of managing the device.? On each and every track that is properly formatted, there is a Home Address marker, followed by a gap.? Then there is the count field for what is called "Record 0".? All count fields are eight bytes in size, and all of them are followed by a gap.? After the count field comes the key area.? The key is optional, so if it is not present then the data can follow immediately after the gap after the count.? If the key is present, it can be 1-255 bytes and is followed by a gap before the actual data portion.?
?
Record 0 is a special record managed by the operating system.? In most cases you cannot read or write Record 0 and it is not available to you.? After the count/key/data areas of Record 0, then there is a gap before the count field for the next record.? Followed by a gap, then the key and a gap, then the data. There is a then a gap before the next count field for the next record.? Rinse and repeat until no more complete count/key/data areas will fit on the track.
?
Note that the terminology when discussing DASD device architecture uses the term "record" to represent the count/key/data area, but in MVS and with the access methods, the data portion is called a block.
?
For a PDS, the first directory block will be after the gap after Record 0 on the track.? For the first directory block, and all subsequent directory blocks, there will be a count field, a gap, a key field, a gap, and the 256 data area of that directory block.? After the last directory block, there will be another count field with a data record length of 0; this is the EOF record.? It also has gaps between its count/key/data areas.? It doesnt count as a block in the total number of directory blocks. If you allocate 10 directory blocks you get ten sets of count/key/data with gaps all in between all of them, followed by the count/key of the EOF block.? The EOF block is the 11th block but isnt counted in your allocation or in any report of how many directory blocks there are.
?
It might seem wasteful to write an EOF record with its count and gap overhead.? But there is a reason.? When the hardware reads a count field with a data length of 0, it causes a special notice on the channel that the DASD is connected to called a 'unit exception'.? This exception is noted by the operating system and that is how it detects that the end of a file, or the end of the directory blocks, has been reached.
?
After the directory portion and when the data portion of the PDS dataset starts, it usually doesnt contain a key field, so typically there is a count, gap, data,gap.? For each block of data.? At the end of the member, there will be a block of zero length; the EOF block.? A new member may or may not follow after the gap after the EOF block.
?
Just because you can't see the gaps doesn't mean they arent there.? You can infer their presence in many cases.? Have you ever seen the DASD table that shows how many blocks of a certain size can fit on a track?? For example, on a 3390 you can fit 12 blocks of 4096 bytes on a track.? That is 4096*12=49152 bytes.? But the total track size of a 3390 is 56,664 bytes.? The lost space is due to all of the gaps between the count fields of each block, and the blocks themselves, and the overhead of the count/key/data and gaps of Record 0.
?
The smaller the block size, the worse it gets. This is because each block has the full overhead of a count/gap/data/gap.? I dont have the exact number of 1-byte blocks that can be written to a 3390 track in front of me, but it is something around 100 of them.?? 100 bytes of data on a 56,664-byte track!? That is awfully wasteful.? And that is why large blocks are recommended with multiple data records in each block.? Even two blocks of 27,920 bytes wastes space:? 27920*2=55,840.? So you are still wasting 824 bytes.? But it is the best we can do. MVS wont let us write more than 32760 bytes in a block.? So no matter how you slice it up, the best you can do is two blocks per track and bear the overhead of the resulting gaps.
?
Regards,
Bob
?
?
?
