Storage Management Issues & Answers By Stephen Pryor Steve Pryor is vice-president of Mitchem Technologies, a firm specializing in DASD storage management and space abend prevention software. Steve has more than 15 years of experience in storage management, disaster recovery, software development and technical support. The Program Management Binder With DFSMS/MVS Release 1.1.0, IBM has introduced some of the most sweeping changes in the MVS operating system in many years. Many of these changes, such as the availability of enhanced dynamic cache management and altered operating system packaging, may not have an immediate impact on users. Other changes, however, such as the rewrite of the linkage editor, will have an important and direct impact on the operation of the system, and therefore are of interest to the storage administrator. IBM has taken advantage of several of the capabilities of MVS/ESA and DFSMS/MVS to provide a new linkage editor, called the Program Management Binder, which lifts many of the old restrictions associated with the DFP linkage editor, and includes improvements in usability and output. The most noticeable change is the complete replacement of the old linkage editor by the Program Management Binder in DFSMS/MVS. The DFP linkage editor is no longer used and the Binder becomes the default linkage editor. The Binder uses the names which have been associated with the linkage editor (e.g., IEWL, HEWL, LKED). Since the Binder is almost completely compatible with the linkage editor, no changes are required to any catalogued procedures or other JCL. Should it be necessary to fall back to the DFP linkage editor, it is still available under the name HEWLF064. Program Objects The major accomplishment of the Binder is to finally allow the use of extended partitioned data sets (PDSEs) for the storage of executable programs. Until DFSMS/MVS and its Program Management Binder, the use of PDSEs was restricted to data files only--programs could not reside in them. Many of the advantages of PDSEs, such as the extensible directory and the elimination of compression, were therefore lost for many installations that did not rush to embrace PDSEs. The Binder introduces a new type of executable program file--the program object. Program objects are analogous to load modules; they are created by the Binder using the same inputs that are supplied to the linkage editor and are loaded into storage and executed in much the same way as load modules. Program objects, however, reside only in PDSEs and are created only by the Binder. The Binder supports both the new program object and the traditional load module format. If the output of the Binder (the SYSLMOD data set) is an ordinary partitioned data set, the Binder creates a load module. If the output data set is a PDSE, the Binder creates a program object. PDSEs cannot contain both program objects and data, however, the first STOW determines whether the PDSE is a program object library or a data library. There is a limited amount of support for the BSAM and BPAM access methods for program object libraries. The STOW DELETE and CHANGE macros are supported, as well as BLDL and FIND. The PDSE directory entries are reformatted by the access methods to appear as PDS directory entries to the issuer. Because only the Binder can create program objects, the STOW ADD and REPLACE macros are not supported. IBM provides an extensive programming interface to the Binder, but alas, does not document the format of program objects. One or two other restrictions are important for the storage administrator to note when considering the use of program objects: Backup/restore programs cannot restore PDSEs to PDSs and vice versa, and of course, the operating system must have DFSMS/MVS available in order to use program object libraries. Storage administrators should account for these restrictions when considering a disaster recovery site. The Binder The Binder removes many of the constraints that were present in the DFP linkage editor. The Binder operates mostly above the 16MB line in 31-bit AMODE and uses generous amounts of virtual storage (2MB is minimum recommended region size) and MVS/ESA data spaces to eliminate nearly all limits on the number of aliases, external names and module size. The archaic limit of 3200 bytes on SYSLIN blocksize is removed and the SYSUT1 DD statement used by the linkage editor for overflow tables is no longer used. One problem that may arise with the use of the Binder involves the SIZE parm, which is still honored, since there are a few instances, such as during SMP processing, when it makes sense to restrict the Binder's use of virtual storage. For most batch processing, however, it is unwise to use the SIZE parm which may result in an error due to insufficient virtual storage. There are a number of minor differences between the Binder and the linkage editor and a few of them are worth noting: o The Binder is much more unforgiving in its syntax checking than the linkage editor. Invalid input, such as unrecognized control statements or parameters, are no longer ignored, but are flagged as errors. o The Binder always allows explicit overrides of an attribute. For example, if the RENT parm is specified when binding a module which includes input modules that are not currently marked RENT, the Binder will honor the parm and mark the module re-entrant. The linkage editor would not. o If the input to the Binder includes conflicting or multiple control statements, such as two ENTRY statements which specify the same entry name, the Binder will honor the last such statement, whereas the linkage editor will honor the first. o The Binder will not replace an executable module with a non-executable module. This prevents modules with errors from accidentally replacing good ones. Because SMP/E processing sometimes replaces modules with empty modules marked non-executable, a new parm, STORENX, must be used to override this default. Other Changes The introduction of program objects required many changes in other areas of Program Management. IEBCOPY, AMBLIST, IEHLIST, IMASPZAP and TSO TEST have all been updated to support program objects. Again, the storage administrator should ensure that the disaster recovery site has the appropriate levels of these products. He or she should also be aware that these utilities may operate somewhat differently on program object libraries than on load libraries. For example, IMASPZAP makes a copy of the program object which is being changed--the original object is not changed. Users who are connected to the original object, including LLA, will not see the change until they disconnect and are again reconnected. Thus LLA may need to be refreshed when zaps are applied to the link list. Conclusion The expertise of the storage administrator must extend across many fields. Even if the Program Management function is not an explicitly assigned part of the storage administrator's job, it has an important impact on data center operation, and on the backup, recovery and DASD management functions the storage administrator often directs. /* Was this column of value to you? If so, please let us know by circling Reader Service No. .