Overview

UDM for z/OS provides the ability to copy load modules.

Syntax

The syntax for copying load modules is the same as any copy operation involving PDS/Es. However, there are some differences in how the copy operation takes place when the command to copy load module(s) is issued.

Source Side

On the source side of the transfer, UDM uses IEBCOPY to unload the load modules, matching the source file mask from the PDS/E in which they reside into a temporary data set. It is this temporary data set that is transferred to the destination system. As a result, when UDM displays the status messages indicating that it is copying a file, it is the name of the temporary file that is displayed, since that is what is actually being transferred.

Destination Side

A temporary file name is also used on the destination side of the transfer. After the temporary file has been transferred, the load modules are 'unpacked,' using IEBCOPY, into a staging PDS/E (also using a temporary data set name). This PDS/E is created using the same attributes as the source PDS/E. From there, IEBCOPY is called a final time to move the load modules from the staging PDS/E to the final destination PDS/E. At this point, all of the temporary files are cleaned up.

The two-step process on the destination side of the transfer is used in case the blocking of the final destination data set does not match that of the source PDS/E.

Copying Load Module Example

Load Module Transfer Script

The following figure illustrates an example script of a load module transfer.

open src=* dst=dst-zos
attrib dst createop=new
copy src='MYHLQ.UDM.TESTLM(*)' dst='YOURHLQ.TEST.LOAD' 

This simple script will copy all of the load modules from a PDS/E on the source system named MYHLQ.UDM.TESTLM to a newly created PDS/E on the destination system named YOURHLQ.TEST.LOAD.

Load Module Transfer Script - Output

The following figure illustrates an example of the output that is received when running a script such as that illustrated above.

Data session established using cipher: NULL-MD5
Two\-party session established with 2 (component 1208550125)
Transfer mode settings:
type=binary 
trim=no 
Session options: 
Keep Alive Interval: 120 
Network Fault Tolerant: yes 
src: Packaging up the following files in 'MYHLQ.UDMTMP.STC07047.R2EED53.N0000000' 
src:  LM1 
src:  LM2 
src:  tmp 
src: 'MYHLQ.UDMTMP.STC07047.R2EED53.N0000000' is being transferred in binary mode 
src: 'YOURHLQ.UDMTMP.JOB07063.RD36420.N0000000' will be used as the destination filname 
dst:  Unpacking from 'YOURHLQ.UDMTMP.JOB07063.RD36420.N0000000' 
src: 'MYHLQ.UDMTMP.STC07047.R2EED53.N0000000' transfered successfully in 0:01:55. 
src:  10566891 bytes read    10566891 bytes written 
src:  Transfer operation complete. 1 file(s) copied in 0:01:55.448. 
src:  10566891 bytes transferred (91529.44 bytes per second) 

At the beginning of the copy operation, the source side indicates that it is packaging the load modules into a temporary data set, MYHLQ.UDMTMP.STC07047.R2EED53.N0000000. This is the temporary data set that is transferred using a data set name of YOURHLQ.UDMTMP.JOB07063.RD36420.N0000000 on the destination side. It is from YOURHLQ.UDMTMP.JOB07063.RD36420.N0000000 that the load modules are unpacked into the temporary staging data set before being moved into the final destination PDS/E, YOURHLQ.TEST.LOAD, which was specified in the copy command.

As you can see, some of the output from a copy operation involving load modules may vary from the output when copying other types of data sets. However, the nomenclature of the copy command has not changed.

Likewise, attributes such as CREATEOP, DIRBLOCKS, and others work the same way with load modules as they do with other types of data sets. This includes the caveat that the attribute settings must be compatible with the type of data set(s) involved in the transfer.

Error Reporting

It is possible for the IEBCOPY portions of a load module transfer to fail. If this occurs, UDM prints the output from IEBCOPY in the transaction log.

Special Attributes

UDM uses heuristics in determining the space attributes for allocating the temporary data sets. The volume that these data sets reside is chosen by the system.

TMPVOLSER Attribute

The TMPVOLSER attribute lets you set the volume on which the temporary files will be allocated.

• Setting this attribute on the source side specifies the location of the temporary sequential data set that will be transferred.
• Setting this attribute on the destination side specifies the volume for the temporary transfer file as well as the volume used by the temporary staging PDS/E.

TMPPRIMSPACE, TMPSECSPACE, and TMPSPACEUNIT Attributes

The TMPPRIMSPACE, TMPSECSPACE, and TMPSPACEUNIT attributes specify the amount of primary space and secondary space used when allocating the temporary files as well as the space unit used.

• When set on the source side, these attributes affect the temporary sequential data set that will be transferred.
• When set on the destination side, these attributes are used in allocating the temporary transfer file and the temporary staging PDS/E.

TMPDIRBLOCKS Attribute

The TMPDIRBLOCKS attribute is used only on the destination side. It specifies the number of directory blocks used by the staging PDS/E.