IBM Mainframe Forum

Greetings,
Using FTP, I am transferring an unloaded PDS (created with IEBCOPY) from one IBM z/OS mainframe to another IBM z/OS mainframe. After the transfer, the receiving mainframe version data format is different from the original although LRECL, BLKSIZE, and RECFM are the same. On the origin host, the file can be successfully loaded to a PDS. On the receiving host no records are loaded and the message returned is:

IEB178I NOT AN IEBCOPY UNLOADED DATA SET - 1ST PHYSICAL RECORD NOT 64 BYTES LONG
File-aid examination confirms this.

Details:

IEBCOPY flat-file: Lrecl=27936, Blksize=27940,Recfm=VS
FTP Batch exection JCL (LOGIN PDS infor has been renamed for security reasons):

//FTP EXEC PGM=FTP,PARM='-r tls (EXIT=4 TIMEOUT 600'
//SYSPRINT DD SYSOUT=*
//OUTPUT DD SYSOUT=*
//INPUT DD DSN=xxx.xxx.xxx(FTPLOGIN),DISP=SHR
// DD *
BIN
SITE RDW LR=27936 BLKSIZE=27940 REC=VS TR PRI=20 SEC=10
PUT 'TEST.EISQA.JCLLIB.UNLOAD'
STATUS
QUIT

I have also used ASCII instaed of BIN and without the RDW keyword, with no change in results....

Thanks for any advice you can provide....
Joe

An IEBCOPY unloaded PDS is a binary variable blocked file, which is tricky to transfer via FTP to another mainframe (don't even try going to a PC or Unix system). The options that have worked for me in the past are:
where the space allocation on the site command can be adjusted as needed. However, the RDW specified on the site and locsite commands, and the mode s command, are not optional.

Thank you for your suggestions, results, alas,were the same. I'm going to hunt for another unload solution...My recourse is to cut n paste the member list....
Joe

If you are going mainframe to mainframe, why not do this:
There's no reason to fiddle with the unloaded IEBCOPY file going PDS to PDS between mainframes. The prompt command is a switch; the default is for it to be on and you don't want to be asked whether or not to transfer each member of the PDS.

as a temporary bypass
XMIT ... outdataset(<***>)
FTP <***>
on the other side/receiving node
RECEIVE ... indataset(<***>)

or
XMIT nodeid.userid <dataset>
on the other side/receiving node
RECEIVE

see
http://publibz.boulder.ibm.com/cgi-bin/ ... s/IKJ4BK80
for the XMIT/RECEIVE details

Thanks again to all...My solultion was to use the TERSE (TRSMAIN) utility to pack the PDS into a binary VS file on the host mainframe, FTP it to the target mainframe, then use the same utility to unpack the VS file into a new PDS file. It was glich-free and fast. I will try some more of the suggestions here--you can never have enough gadgets in the toolkit.

Robert Sample wrote:If you are going mainframe to mainframe, why not do this:

Select all

cd 'destination PDS name'
lcd 'source PDS name'
prompt
mput *
quit

There's no reason to fiddle with the unloaded IEBCOPY file going PDS to PDS between mainframes. The prompt command is a switch; the default is for it to be on and you don't want to be asked whether or not to transfer each member of the PDS.

Hi, tried this and found that each PDS member became a separate file on the target machine. i.e., PDS.FILE(MEM1) transferred to PDS.FILE.MEM1
The best solution I've found was the TERSE utility because it preserves the orginal host member statics. The SAS/IEBUPDTE removes them and the individual member transfers replaces them with current SYSUID, Time, and date.
Thanks again!
Joe

Interesting -- mainframe to PC and PC to mainframe, the cd to the PDS file name causes member names to be transferred into or out of the PDS. I've also used the same technique for mainframe to mainframe transfers without any problems -- and PDS members became PDS members.