<SNIPPAGE>
> ADRDSSU uses large block sizes that FTP can't handle.  Terse / unterse
> took care of that.

The ADRDSSU data sets had a blksize of less than 32K because I set the 
blksize via JCL. That blksize was honoured and the dataset preallocated in 
the target system. Also, the transport copy of the catalog was NOT 
generated via ADRDSSU, and it was unusable on the new system after being 
FTP'd. I still suspect some incompatibility.

Barbara
<SNIPPAGE>

Barbara:

My apologies, I had not correctly recognized some of the issues you bring 
up. I think I've been hitting the same thing between different IBM Labs 
and levels of z/OS.

I have been forced to use BINARY transfers to get around an issue with 
code pages when using FTP. 

And the other issue that is not being addressed straight on is, DFSMS made 
a change to their support and IOS(?) made a change to the device type 
information allowing 3490 type drives to now do LBI (that is, 256K blocks 
which is beyond the old 64K blocks). So if you picked up maint that solved 
that, you will get an ADRDSSU output that is greater than 64K blksize. I 
have forgotten which z/OS level initially implemented this (caused C:D for 
z/OS support some heartburn). I think this is why the terse/unterse is 
working for you. I also believe that unless you are doing BIN xfers with 
FTP, you are being tripped up with code page issues (the receiving system 
could not read XMIT files or other special format files because they had 
been "corrupted.").

One of the circumventions for this ADDRDSSU LBI problem for FTP is to put 
in the exit that forces ADRDSSU to use 32K as the max blocksize. This may 
be something you want to consider as it will not be as efficient with your 
tapes.

Knowing that I worked on C:D for z/OS, you might ask why I'm not using it. 
Well, in my new position, C:D for z/OS is not installed in the other labs 
(yet) where I work now. So I have to do FTP and I've been hitting problems 
that C:D already had to deal with, concerning ADRDSSU written tapes. And I 
realized this morning that some of the symptoms you have described were 
ones I had been battling in copying data between two labs. 

Regards,
Steve Thompson
IS Build group

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to