 |
As long as your FTP client and FTP server are both at
the z/OS® Communications Server
V2R10 or later, you can use FTP to transfer MVS™ load modules between load libraries on different
hosts or the same host. MVS load
modules transferred, using z/OS Communications Server V2R10 or later support, are executable on
the target system. A load module can be specified by its real name
or by one of its alias names, and in either case, all aliases are
transferred with each load module. Load module transfer (LMTR) is
also supported for proxy transfer, in which case all three hosts (client,
primary server, and secondary server) must be z/OS Communications Server V2R10 or later.
Load module transfer processing (at z/OS V1R2
Communications Server or later) makes use of the IEBCOPY system utility, which must be
available on both the origin and destination hosts.
The following FTP file transfer commands will properly
transfer MVS load modules: - get
- mget
- mput
- mvsget
- mvsput
- put
Because of the special requirements of MVS load modules, there are some additional restrictions: - Do not transfer nonexecutable load modules, or load modules of
size 0 or undefined size. Unpredictable results will occur.
- The current working directory on both the client and the server
must be the source or destination load library. A load library
is a PDS or PDSE with RECFM=U.
- Only member names can be specified. No fully qualified names
can be specified.
- File rename is not supported on load module transfer.
- Load modules can be transferred only between the same types of
libraries. For example, PDS to PDSE transfer is not allowed.
- If load modules are being sent to or from the z/OS FTP
client, the client must be started from one of the following environments:
- TSO terminal session
- TSO REXX
- TSO batch
- TSO background
- Unix System services terminal session
- A load module loading from a temporary data set will always be
a REPLACE operation, overwriting existing members. LMTR is not performed
in STOU mode (the user has toggled SUNIQUE on).
- There is no prompting on mput and mget subcommands. All files
that match the mask provided are transferred.
In most cases where load module processing cannot be performed,
including failure to abide by the restrictions given above, FTP completes
the file transfer using normal processing. Any load modules transferred
with normal processing are not executable on the target system. For the examples shown below, the following assumptions
are made:
The following example is a sample session involving a load module
transfer with debug/trace on. (For clarity, user input is shown offset
to the left and notes are contained within // characters.) 220-FTPD1 IBM FTP CS V1R2 at MVS097, 21:16:25 on 2003-01-16.
220 Connection will not timeout.
NAME (9.67.43.61:USER1):
user1
>>> USER user1
331 Send password please.
PASSWORD:
>>> PASS
230 USER1 is logged on. Working directory is "USER1.".
Command:
cd 'user.linklib'
>>> CWD 'user.linklib'
250-The working directory may be a load library
250-The working directory "USER.LINKLIB" is a partitioned data set //1//
Command:
lcd 'user1.testlib'
Local directory might be a load library //1//
Local directory name set to partitioned data set USER1.TESTLIB
Command:
get oping
>>> XLMT PDS 0 oping //2//
250 PDS 53864 - send next command for load module transfer //2//
>>> PORT 9,67,43,65,4,41
200 Port request OK.
>>> RETR oping
125-Transferring load module //2//
125 DCB 32760 32760 //2//
IEBCOPY MESSAGES AND CONTROL STATEMENTS //3// PAGE 1
IEBCOPY FMID HDZ11D0 SERVICE LEVEL UW90570 DATED 19990520 DFSMS
1.5.0 MVS SP6.0.8 HBB6608 CPU 9672
USER1 OS390R5 OS390R5 16:20:59 TUE 16 NOV 1999 PARM=''
STANDARD DD NAMES- SYSIN SYSPRINT SYSUT1 SYSUT2 SYSUT3
SYSUT4
OVERRIDING DD NAMES- SYS00158 SYS00159 SYS00157 SYS00156 SYSUT3
SYSUT4
VL GETMAIN REQUESTED 280K TO 1M BYTES. OBTAINED 1M.
COPY OUTDD=SYS00156,INDD=((SYS00157,R))
ORIGINAL PDS (BEFORE UNLOAD) WAS RECFM=U BLKSIZE=32760 LRECL=0
KEYLEN=0 OPTCD=X'20' UCBTYPE=X'3010200F' INDC=X'00'
ALLOCATED 2 CONTIGUOUS BUFFERS EACH 111K BYTES. WORK AREA HAS 757K
BYTES AVAILABLE.
COPYING FROM PDSU INDD=SYS00157 VOL=
DSN=SYS99320.T162100.RA000.USER1.TEMPXLMT.H01
TO PDS OUTDD=SYS00156 VOL=CPDLB1 DSN=USER1.TESTLIB
CONTROL TABLE IS 20 BYTES LONG. WORK AREA HAS 757K BYTES AVAILABLE.
ALLOCATED SECOND BUFFER OF 745K BYTES. FIRST BUFFER IS NOW 221K
BYTES. WORK AREA HAS 11974 BYTES AVAILABLE.
FOLLOWING MEMBER(S) LOADED FROM INPUT DATA SET REFERENCED BY SYS00157
EZACDPIN HAS BEEN SUCCESSFULLY LOADED //4//
OPING HAS BEEN SUCCESSFULLY LOADED //4//
2 OF 2 MEMBERS LOADED FROM INPUT DATA SET REFERENCED BY SYS00157
THERE ARE 135 UNUSED TRACKS IN OUTPUT DATA SET REFERENCED BY SYS00156
THERE ARE 23 UNUSED DIRECTORY BLOCKS IN OUTPUT DIRECTORY
RELEASED 1016K ADDITIONAL BYTES.
END OF JOB - 0 WAS HIGHEST SEVERITY CODE
250 Transfer completed successfully.
63084 bytes transferred in 0.005 seconds. Transfer rate 12616.80 Kbytes/sec.
Command:
In this next example, the user attempts to transfer a load module
and rename the load module. As this is not supported, load module
processing will exit and normal processing will take over. The transferred
load module will not be executable on the target system. cd 'user.linklib'
>>> CWD 'user.linklib'
250-The working directory may be a load library
250-The working directory "USER.LINKLIB" is a partitioned data set
Command:
lcd 'user1.testlib'
Local directory might be a load library
Local directory name set to partitioned data set USER1.TESTLIB
Command:
get oping ping
Load module transfer does not support load module rename //5//
>>> PORT 9,67,43,66,4,41
200 Port request OK.
>>> RETR oping
125 Sending data set USER.LINKLIB(OPING)
250 Transfer completed successfully.
61984 bytes transferred in 0.190 seconds. Transfer rate 326.23 Kbytes/sec.
Command:
Notes: - When a cd or lcd subcommand is performed, the user will be notified
if the new current directory is eligible for load module transfer
processing. If this message or reply is not seen when changing to
a directory, load module transfer will not be attempted.
- There are additional flows between the client and server for load
module transfer.
- The IEBCOPY system utility is invoked by FTP as part of load module
transfer processing. Note that this output is seen only when running
with debug or trace on. Otherwise the IEBCOPY output is placed in
the syslog.
- The actual load module and all of its aliases are transferred,
even though (in this case only) the alias was specified by the user.
- When load module transfer processing cannot be performed, the
user is warned and the transfer might be completed using normal processing.
The data set USER.TESTLIB(PING) is not executable on the client system.
|
z/OS Communications Server: IP User's Guide and Commands
Copyright IBM Corporation 1990, 2013