System-Managed Storage and PDSEs

DFSMS: What is System Managed Storage? Part 8

This is part eight of the series that began with What is System-Managed Storage?

What are PDSEs?

PDSE stands for partitioned data set extended, a type of data set introduced in MVS/DFP 3.2.0. A PDSE contains an indexed directory and members that are similar to the directory and members of a partitioned data set (PDS). Because a PDSE provides similar function to a PDS, it can, in most cases, be used in place of a PDS.

Most PDSE interfaces are indistinguishable from PDS interfaces for accessing a directory or member. PDSEs and PDSs are processed using the same macros and access methods and records are stored in members described by a directory. While a PDS can be either SMS-managed or non-SMS-managed, PDSEs must be SMS-managed.

Why Should I Use PDSEs?

PDSEs were designed to remove the architectural limitations of PDSs. For example, the size of a PDS directory is fixed, regardless of the number of members, while PDSE directories are flexible and expand to fit the stored members. Also, the system reclaims space automatically when a member is deleted or replaced, and returns it to the pool available for allocation to other members of the PDSE. The space can be reused without compressing the data set.

Some other advantages of PDSEs are:

• Searching directories is more efficient because they are indexed and can be cached
• You can create multiple members at the same time
• Sharing occurs at member and data set levels
• PDSEs can expand to up to 123 extents
• Program objects stored in PDSEs allow the program management loader to load only part of a program before passing control
• PDSE program libraries allow more control information to be stored in the directory than partitioned data sets do
• PDSE program libraries offer superior buffer management and caching capability
• Alias entry management for PDSE libraries is better than that offered by PDS libraries
• PDSEs can be shared by all the processors in a multisystem complex

Defining PDSEs

If you install DFSMS/MVS with SMS active, you can allocate PDSEs in SMS storage groups. The following parameters are required:

• Directory space greater than zero or DSORG=PO
• DSNTYPE=LIBRARY

They can be specified:

• in a data class definition
• on a JCL DD statement
• via the LIKE keyword
• on a TSO/E ALLOCATE command
• on the DYNALLOC macro
• via installation default

Since PDSEs must be SMS-managed, a storage class must be assigned to the data set. Your storage administrator can also set DSNTYPE=LIBRARY as an installation default via the DSNTYPE keyword in the IGDSMSxx member of SYS1.PARMLIB.

Sharing PDSEs

Unlike PDSs, PDSEs can be shared at both data set and member levels. Users on one or more systems can access a PDSE simultaneously to create, read, or replace members of the PDSE concurrently.

Your installation can define the extent of PDSE sharing. PDSEs can be shared between users of a single processor only (normal) or shared between users on any processor in a multisystem complex (extended). You select the type of sharing by using the PDSESHARING keyword in the IGDSMSxx member in SYS1.PARMLIB.

Extended sharing is available only when all the systems are running DFSMS/MVS 1.1.0 or higher and PDSESHARING(EXTENDED) has been specified. Extended sharing applies when a PDSE is allocated with DISP=SHR; it can not be used with DISP=OLD.

With extended sharing, any number of users or systems can concurrently share a PDSE or members within it for input (read) or output (write). While multiple members can be updated by different users on the same system, only one user can update a member at a given time. In addition, only one system can access the PDSE when update is being done.

PDSE Libraries

There are two types of PDSE libraries: data libraries (available with MVS/DFP 3.2.0 and higher) and program libraries (available with DFSMS/MVS 1.1.0 and higher). The first member stored determines the library type. Once the library type has been determined, only members of the same type can be stored in that library.

Data libraries, as the name implies, are used to store data. Program libraries are used to store program objects, which are all or part of a computer program in a form suitable for loading into main storage for execution. Program objects stored in PDSE program libraries have fewer restrictions than load modules.

When Should I Use PDSs Rather Than PDSEs?

You should continue to use PDSs rather than PDSEs when:

• you need a checkpoint data set; PDSEs cannot be used as checkpoint data sets
• you are defining a program library which is used during IPL such as SYS1.NUCLEUS, SYS1.LPALIB or SYS1.SVCLIB
• you need to ship the data set to or share the data set with a system that does not support PDSEs
• an application which uses the data set does not support PDSEs (for example, it uses EXCP, EXCPVR or XDAP)
• an application which uses the data set is dependent on processing short blocks or SAM record null segments

In Summary

As you can see, PDSEs provide a number of benefits over PDSs:

• They can occupy up to 123 extents rather than only 16
• Directories expand dynamically, eliminating problems with full PDS directories
• Directories are indexed, allowing a faster search than sequential PDS directory search
• Records in a PDSE are reblockable, making PDSEs device independent
• Sharing is provided at data set and member levels rather than only at data set level
• Because of improved sharing, multiple members can be created at the same time
• There is no need to compress PDSEs; space is automatically reclaimed

[ Previous Article | Next Article | All Articles ]