Hi :)

I am trying to understand how PDSs are allocated in a 3390.

Facts:

• TSO001: 3390-1, 56,664 bytes/track
• PDS directory block: 256 bytes/dirBlock
• PDS EOF record: unknown

Sequential Data Set

With attributes:

• Record format: FB
• LRECL: 80
• BLKSZ: 27,920
• Primary space: 1 track
• Secondary space: 0

My expectations:

• Blocks per track: 2
  • 56,664 bytes/track / 27,920 bytes/block = 2.0295 blocks/track
• Logical records per block: 349
  • 27,920 bytes/block / 80 bytes/record = 349 records/block
• Max. logical records per track: 698
  • 349 records/block * 2 blocks = 698 records

I am able to confirm my expectations with the following card decks (please, find attached):

• fill-seq-ds-rc0.jcl (Creates a sequential data set with 698 logical records. RC=0)
• fill-seq-ds-sb37.jcl (Creates a sequential data set with 698 logical records, and ABENDs when inserting the logical record 699. SB37)

Partitioned Data Set

With attributes:

• Record format: FB
• LRECL: 80
• BLKSZ: 27,920
• Primary space: 1 track
• Secondary space: 0
• Directory blocks: 1

Directory Blocks Space

My expectations:

• 1 dirBlock = 256 bytes
• Min. dirEntry = 8+3+1=12
• Max. entries = 21
  • 256 / 12 = 21.333

I am able to get 20 members with the following card decks (please, find attached):

• fill-pds-dblk-rc0.jcl (Creates a PDS with 20 members, 1 logical record each. RC=0)
• fill-pds-dblk-sb14.jcl (Creates a PDS with 20 members, and ABENDs when creating the 21st member. SB14)

Why 20 and not 21? What am I missing?

Member Space

My expectations:

• Space taken by directory blocks: 4 records
  • 256 bytes / 80 bytes/record = 3.2 records
• Seq. DS max. logical records = 698
• PDS max. logical records = 694
  • 698 records/track - 4 records = 694 records

I am able to create one member with max. 667 records with the following card decks (please, find attached):

• fill-pds-1member-rc0.jcl (Creates a PDS with 1 member with 667 records. RC=0)
• fill-pds-1member-sb37.jcl (Creates a PDS but ABENDs adding the member with 668 records. SB37)

Why 31 records less? What am I missing?

I am only able to create 14 members with 460 records total. 13 members with 34 records and 1 member with 18 records (please, find attached):

• fill-pds-20members-rc0.jcl (Creates a PDS with 14 members. RC=0)
• fill-pds-20members-sb37.jcl (Creates a PDS with 13 members, but ABENDs adding the 14th member with 19 records. SB37)

Why 238 records less? What am I missing?

Kind Regards

开云体育

Each 256-byte directory block has a 2-byte field which indicates the length within the block of the entries it contains, so only 254 bytes may be used to hold the entries themselves - you should be doing 254 / 12 instead of 256 / 12.

That still gives 21, however.

I'm not an expert on the exact conditions, but entries can vary in length, so I suspect that for some reason your entries are more than 12 bytes long, as 12 bytes is the maximum entry length that will allow 21 entries to fit in one directory block.

On 31/10/2024 7:48 am, jacampbellaus via groups.io wrote:

Should have added - a PDS directory block is a keyed block.

Yes, to calculate the number of directory blocks that will fit on a track, you need to account for 256-byte data blocks each with an 8-byte key.

Also, to calculate the space required by a PDS (as compared to a sequential data set) you need to account for an EOF marker at the end of the PDS directory and an EOF marker at the end of every member.? Most of the time, meaning for most DASD types, when aiming for the PDS directory to occupy an integral number of tracks, the trick is to multiply the desired number of tracks by the number of PDS blocks per track (for that device type), and then subtract one to leave room for the EOF marker.

A sequential data set does not end with an EOF marker - although it could be read successfully if it did.

The VTOC entry of PS (and PO) data sets contains the TTR of the last record written.? With DISP=MOD (or OPEN EXTEND (or OUTINX) with DISP=OLD or DISP=SHR), the first block appended will be the block after the previous "last block written".? The track balance field in the VTOC informs the access method as to what size is the largest bock that will fit on the track with the previous last block. Accordingly, the first newly appended block will either fit on the previous last track or will be the first block on the next (relative) track.

DISP=MOD and OPEN EXTEND are not allowed for PDSes (or even for PDSEs).

IBM's ISPF option 3.2 always did an OPEN/CLOSE cycle on a newly allocated sequential data set.? We used to say that it wrote an EOF marker, but probably what it really ended up doing was erasing all blocks on the first track.? Compare this to a PGM=IEFBR14 (or any other program) step that creates a new sequential data set with JCL.? Make the block size big enough and you can read any residual data that previously occupied those tracks (assuming no RACF erase-on-scratch facility or similar).

Later on, SMS-managed sequential data sets allocated by JCL also got the EOF marker or first track erased thing done.

RFE option 3.2 does not do an open/close cycle when allocating new sequential data sets.
Rob can tell us what happens with the equivalent case when using RPF.

Cheers,
Greg

Hi :)

Thank you all.

I was able to verify what happens inside the directory block by creating my own uncompressed 3390 disk and inspecting it with an hexadecimal editor.

PDS Directory block

I was able to confirm the "end marker” inside the 254 bytes for directory entires. That end marker takes 8 bytes, all Bytes 0xFF, ie. 0xFFFFFFFFFFFFFFFF.

I also found out that:

• when creating a PDS member using with JCL DD, it uses the minimal 12-Bytes-long directory entries, so it fits 20 members created by JCL DD.
• when creating PDS members using ISPF (M.1.2 or 2), it uses 42-Bytes-long directory entries, so it fits 5 members created via ISPF.

PDS Member records

Between the directory block and the first member, there is a 16-Bytes-long separator (END marker?).

eg.

00 00 00 02 02 00 00 00 00 00 00 02 03 00 05 A0
             |                       |
             |                       '- First record of member 1 (as in TTR)
             '- Last record of Directory blocks area (as in TTR)

There is also a 16-Bytes-long separator between each member (EOF marker?)

eg.

00 00 00 02 04 00 00 00 00 00 00 02 05 00 05 A0
             |                       |
             |                       '- First record of next member (as in TTR)
             '- Last record of previous member (as in TTR)

And after the last member

00 00 00 02 2C 00 00 00 FF FF FF FF FF FF FF FF
             |
             |
             '- Last record of last member (as in TTR)

Number of records per member

What I still cannot understand is the number of records per member. I can see that the space is available in the track.

Do you know where should I look?

---

Kind Regards

Sergio Lindo Mansilla

What I still cannot understand is the number of records per member. I can see that the space is available in the track.

You are looking at the way the emulated disk stores data, not the way an actual physical
3390 disk stored them. Each has different sets of overheads on the data. While you don't
see the overheads that 3390s had, the algorithim writing data records has to take account of
them.

The available space that you see in the track is the space that a physical 3390 would have
used for its overheads. A simple comparision of the largest possible block size (56664) and
2xlargest 1/2 track block size (27998) shows that the overhead of that second block is 334
bytes.

If you want to understand what you are looking at in an emulated disk


The format of a CKD header is
nn - record # on track.
kk - length of key field (00 if none)
dd dd - length of data

kk dd dd = 00 00 00 is an EOF merker


James Campbell


On 2 Nov 2024 at 17:44, Sergio via groups.io wrote:

Hi :)

Thank you all.

I was able to verify what happens inside the directory block by creating my own uncompressed 3390 disk and inspecting it with an hexadecimal editor.

### PDS Directory block

I was able to confirm the "end marker" inside the 254 bytes for directory entires. That end marker takes 8 bytes, all Bytes 0xFF, ie. `0xFFFFFFFFFFFFFFFF`.

I also found out that:

- when creating a PDS member using with JCL DD, it uses the minimal 12-Bytes-long directory entries, so it fits 20 members created by JCL DD.
- when creating PDS members using ISPF (M.1.2 or 2), it uses 42-Bytes-long directory entries, so it fits 5 members created via ISPF.

### PDS Member records

Between the directory block and the first member, there is a 16-Bytes-long separator (END marker?).

eg.

```
00 00 00 02 02 00 00 00 00 00 00 02 03 00 05 A0
| |
| '- First record of member 1 (as in TTR)
'- Last record of Directory blocks area (as in TTR)
```

There is also a 16-Bytes-long separator between each member (EOF marker?)

eg.

```
00 00 00 02 04 00 00 00 00 00 00 02 05 00 05 A0
| |
| '- First record of next member (as in TTR)
'- Last record of previous member (as in TTR)
```

And after the last member

```
00 00 00 02 2C 00 00 00 FF FF FF FF FF FF FF FF
|
|
'- Last record of last member (as in TTR)
```

### Number of records per member

What I still cannot understand is the number of records per member. I can see that the space is available in the track.

Do you know where should I look?

---

Kind Regards

Sergio Lindo Mansilla

开云体育

开云体育

开云体育

Hi Andre,

It was explained in this post from November 4th