I’ve been using PDSE’s for years. I thought that PDSE was a slight improvement to a PDS in that you did not have to compress PDSEs like you had to with PDSs, and binding programs require a PDSE.
I’ve found there is a big difference. IBM documents it here. For me the difference are
- A PDSE can be larger than a PDS – it can have more extents.
- When you delete a member from a PDS, the space is not reclaimed. When you add a member to a PDS it uses up free space “from the free end”. When the PDS is full you have to compress it, and reorganise the space. With a PDSE the data is managed in 4KB pages. When a member is deleted the space is available immediately
- With a PDS you can get “directory full”, if you did not allocate enough directory blocks when you created the data set. With a PDSE, if it needs a new “directory block” it gets any free block.
- The directory of a PDS is in create order. To find a member you have to search the directory. With a PDSE the directory is indexed.
- With a PDS only one thread can update it at a time. With a PDSE, multiple tasks can update it – including in a sysplex.
- Old fashioned link edits can go into a PDS or a PDSE. The binder (the enhanced likage editor) can only store modules in a PDSE. One reason is that there is more information in the directory entry.
- PDSEs are faster. When you read a PDS there is IO to the disk, firstly to get the directory blocks, to search for the entry, then to read the member from disk. With a PDSE, the system address space SMSPDSE may have cached directory entries, or the pages themselves, and so eliminated the need for IOs. Even if it is not cached the directory search may be shorter.
- Some system load libraries have to be PDS and not PDSE, as the PDSE code may not be loaded early in the IPL.
You can find out about PDSEs here