Why does COBOL V6 use PDSEs for executables?

As detailed in Changes in compiling with Enterprise COBOL Version 5 and Version 6 in the Enterprise COBOL for z/OS Migration Guide, COBOL V6 executables must reside in a PDSE and can no longer be in a PDS.

This section describes some of the rationale for this change in behavior.

First, here is background information regarding PDS. When using PDS, customers reported problems in several areas:
  • The need for frequent compressions
  • Loss of data due to the directory being overwritten
  • Performance impact due to a sequential directory search
  • Performance delay if member added to beginning of directory
  • When PDS went into multiple extents

In addition, PDS data sets cannot share update access to members without an enqueue on the entire dataset. More seriously though, a PDS library has to be taken down in order to perform compression to reclaim member space, or for a directory reallocation to reclaim wasted spaced (also known as gas).

Both of these can cause application downtime in production systems and are therefore very undesirable.

PDSEs, which were introduced in 1990, were designed to eliminate or at least reduce these problems and for the most part they have been successful. The initial rollout of PDSEs was rocky, and due to these problems long ago, many sites continue to avoid PDSEs to this day.

On the other hand, many other sites have moved their COBOL load libraries to PDSEs, and the process to do so is fairly mechanical. For example:
  • Allocate new PDSE datasets with new names
  • Copy Load Modules into PDSEs - these are converted to Program Objects
  • Rename PDSs, then rename PDSEs

In fact, Enterprise COBOL has required program objects, therefore, PDSE for executables since 2001 for features such as long program names, object-oriented programs and for DLLs using the binder instead of the prelinker.

Only PDSEs (and z/OS® USS files) can contain program objects, and this allows program management binder to solve some long standing existing problems using these program object features.

For example, once the 16M text size limit of load modules was hit, the only solution was an expensive redesign or refactoring of the program in order to make it smaller. With program objects the text size limit is increased to 1G.

This extra space also allows the COBOL compiler to perform more advanced optimizations that may increase program literal area, and ultimately object, size (with the goal of course of improving runtime performance). There are other advantages as well for COBOL using program objects:
  • QY-con requires program objects
  • Condition-sequential RLD support requires program objects (leading to a performance improvement for bootstrap invocation)
  • Program objects can get page mapped 4K at a time for better performance
  • Common reentrancy model with C/C++ requires program objects
  • Looking into potential for the future XPLINK requires program objects and will be used for AMODE 64
A related issue is the different sharing rules across a SYSPLEX system. Unlike PDS libraries, PDSE data sets cannot be shared across SYSPLEX systems. Therefore, if existing pre-V6 PDS based COBOL load libraries are being shared, then V6 PDSE based load libraries can be moved using the following process:
  • One SYSPLEX can be the writer/owner of master PDSE load library (development SYSPLEX)
  • When PDSE load library is updated, push the new copy out to production SYSPLEX systems with XMIT or FTP
  • The other SYSPLEX systems would then RECEIVE the updated PDSE load library