Load module transfer failures

This topic describes failures when transferring MVS™ load modules.

If the MVS load module transfers, but is not executable on the target system:
  • Ensure that all hosts involved in the load module transfer are at the Communications Server for OS/390® V2R10 level or higher.
    • For proxy transfers, both servers and the client must be Communications Server for OS/390 V2R10 or higher.
  • Ensure that the user did not attempt an operation that is not supported by load module transfer:
    • Ensure that the user did not attempt to rename the load module on transfer.
    • Ensure that the working directory on both the current and target systems is a load library of the correct type. An MVS load library for purposes of this support is a PDS with RECFM=U or a PDSE. Files can only be transferred between the same types of load libraries. This means that a PDS load library member must be transferred to another PDS, and a PDSE load library member must be transferred into another PDSE. The FTP client displays a terminal message EZA2841I Local directory might be a load library when a user changes local directory into a PDS or PDSE eligible for load module transfer support. The FTP server sends a 250-The working directory might be a load library reply to the client when a CWD command is processed that causes the server working directory to become a PDS or PDSE eligible for load module transfer support. If both the message and the reply are not seen when changing directories before a transfer, load module transfer processing is not be used to transfer any files between the two directories.
    • Ensure that the load modules are transferred by member names only. The current working directory on both the target and destination systems must be the load library. Fully qualifying the member names is not permitted.
  • Ensure that there are no problems with the IEBCOPY invocation. If an error is detected with an IEBCOPY invocation, the FTP server or client furnishes the IEBCOPY SYSPRINT output as messages to either the console (in the server's case) or the terminal session (in the client's case). Specify the FSC(2) debug option for the general trace for the FTP client and for the FTP server to display the IEBCOPY SYSPRINT output for both successful and unsuccessful transfers. At the client, enter debug fsc(2) before the transfer. See Start tracing for information about how to set the trace for the server.
If the MVS load module fails to transfer, check the following:
  1. If Reload of the load library failed or Unload of the load library failed messages or replies are seen, then these messages indicate a problem with a call to the IEBCOPY system utility. Ensure that the IEBCOPY system utility is installed on the system and available to be called from application programs. If so, examine the FTP debug trace to determine whether IEBCOPY was successfully invoked (see the Diagnosing FTP server problems with traces for information about activating FTP syslog tracing.) (Some client environments, particularly REXX scripts running under the UNIX System Services shell, are not fully authorized to call IEBCOPY). If IEBCOPY was successfully invoked, examine the IEBCOPY SYSPRINT output (described above) to see whether IEBCOPY reported any errors.
  2. If allocation failure messages or replies are seen, then:
    • If the data set whose allocation failed is either the source or destination load library, ensure that no other process has allocated the load library for exclusive use.
    • If no data set name appears, or if the data set name ends in the characters XLMT, ensure that sufficient temporary DASD is available on the system. Load module transfer requires the use of sufficient temporary DASD to hold all data that could be transferred in one transfer command. Consider breaking up large mget or mput transfers into smaller groups to reduce the amount of required temporary DASD. If sufficient temporary DASD is not immediately available, then the setting of the AUTOMOUNT/NOAUTOMOUNT site option regulates whether FTP attempts to mount additional temporary storage to complete a load module temporary file allocation request.
  3. If ABEND X’B3700000’ occurs, this can indicate that a DASD storage shortage happened when FTP used IEBCOPY to copy the data from the original load module to a temporary data set. Ensure that all the members in the original load module PDS or library have correct size information in the directory. Do not transfer nonexecutable load modules, or load modules of size 0 or undefined size.

If the MVS load module transfer hangs, the system is probably waiting for temporary DASD to be mounted. If your system does not respond promptly to mount requests for temporary DASD, consider setting the NOAUTOMOUNT (LOC)SITE option about the hanging system, and breaking up large load module transfer mgets and mputs into smaller requests to reduce the requirement for temporary DASD.

Parent topic: Data transfer problems