longpelaexpertise.com.au/ezine/ProgramObjectsComingSoon.php?ezinemode=printfriend

LongEx Mainframe Quarterly - May 2014

To run any program in z/OS, you call an executable module, and things go from there. From the early days of z/OS (or MVS as it was known then), this executable module was called a 'load module'. And they're still called that today. However load modules are moving aside for a new type of executable: 'Program Objects.' This article looks at Program Objects, and why they're coming soon to your z/OS system.

Why Program Objects?

In OS/390 1.1, Program Objects were first introduced to the System z mainframe world. So by now they can't be thought of as new: OS/390 1.1 was released in 1995. Program Objects came to overcome some of the restrictions of the original load modules, especially for programs written in C/C++, or those designed for z/OS UNIX. For example, load modules cannot have external references longer than 8 characters, cannot have more than 32767 of them, and must be in a PDS. Program Objects can have external references up to 32767 characters in length, can have as many of them as they like (memory permitting), and are in PDSEs or z/OS UNIX directories. Ideal for C and UNIX programmers. Remember PDSEs, this is particularly interesting.

Program Objects can also provide performance benefits. For example, PDSE directories are more efficient than those in PDS, so modules are located faster. In the right circumstances, a Program Object can commence executing before the entire module is loaded, particularly handy for very large programs. Some tests have also shown that they use up less CPU when loaded, depending on the circumstances and a few system parameters. Those wanting the performance enhancement that XPLINK brings for C programs need Program Objects, as do those looking for DLL support for dynamic calls.

Program Objects come with other goodies as well. They can be stored in a compressed format without changing the program source, they can be digitally signed for security, and their directory cannot fill up (providing there's room left in the PDSE itself). But perhaps best of all, they don't need to be regularly compressed to reuse space left from deleted modules.

A final advantage is that extent information for PDSEs is dynamically updated. Load module libraries that grow into a new extent can cause problems with the systems using them. For example, load module libraries in the z/OS Linklist cause problems when adding an extent (which is why most Linklist libraries are only one extent). Similarly DB2 Stored Procedure Address spaces must be restarted when Stored Procedure load module libraries add an extent. With PDSEs, this all goes away.

So Program Objects sound cool. And converting to them is easy. IEBCOPY will do it. DFSMSdss (DFDSS) can convert hundreds of load module libraries to PDSE Program Objects in one job. No recompiles, no rebinds, no JCL changes. Even better, there's no IMS or CICS program definition changes, and no DB2 stored procedure definition changes. They can be added to the z/OS Linklist without any special configuration or changes. And the bottom line is what we want to hear: programs will execute as before.

Why You Don't Use Them Yet

Unless you're z/OS site is doing a lot of programming in C or with z/OS UNIX, there's an excellent chance you're not using Program Objects yet. And there are some good reasons for this.

We've already talked about how Program Objects must be in PDSEs or z/OS UNIX. To access these, the PDSE address space must be active and/or the z/OS UNIX address spaces must be active. So most system routines, and programs needed in the early stages of an IPL can't be Program Objects (though they can be in the z/OS Linklist). This includes LPA modules in the LPALIST (but not those dynamically added later). Similarly many exits still need to be load modules.

Tools analysing or working with load module libraries may not work with PDSEs and Program Objects. For example, a program analysing load libraries by opening a PDS directory will fail with PDSEs. Similarly programs reading load module libraries (as apart from loading modules from them) won't work. You can't browse a PDSE with Program Objects from an application program. Finally, PDSEs with Program Objects will take up more DASD space than the equivalent load module libraries, though in today's mainframe sites, this is unlikely to be a concern.

Anyone sharing load module libraries outside of a GRS-plex (for example, using CA-MIM) will also have problems. In this case, there will need to be a separate copy in every GRS-plex. No sharing of PDSEs outside of a GRS-plex or Parallel Sysplex.

Those sites relying on load module caching products such as CA PMO and CA PDSMAN will have had another reason to avoid Program Objects - these products don't manage or cache them, and probably never will. What's more, putting a Program Object library at the top of a STEPLIB concatenation will impact performance: that Program Object library will always be searched without PMO/PDSMAN benefits, before the caching can commence with load modules further down the concatenation.

And of course converting to Program Objects takes time, and incurs a risk. So many managers seeing little benefit of Program Objects have no immediate plans to convert.

Why They're Coming

The chances are that you already have Program Object libraries. That's because software vendors, particularly IBM, are starting to ship products as Program Objects. For example DB2 required SDSNLOAD and others to be a PDSE from version 9, released in 2007. Websphere MQ wasn't far behind, shipping SCSQAUTH as a PDSE from version 7.0.1 in 2009.

However the big news is that you will start compiling your application programs as Program Objects. And it may be soon.

In June 2013, IBM announced the latest Enterprise COBOL compiler. This compiler boasts performance advantages, and a few other nice features. But there's a catch, and you've probably guessed it by now. Enterprise COBOL 5.1 will only produce Program Objects. No more load modules. No news about the other compilers, which all can still produce load libraries. But the smart money is that these will follow suit, sooner or later.

Conclusion

Program Objects are coming to your z/OS system whether you like it or not. In fact, they're already there. Your applications will sooner or later be brought into the Program Object camp, and you'll get a lot of benefits as part of the package. The really good news is that converting to Program Objects isn't difficult or dangerous: the technology has been around since 1995.

David Stephens