Long ago I found the following details and sent it to my team. You may find the
extra details useful:
++++++++++++++++++++
Use the following to FTP a DFDSS Dump.
First, issue the QUOTE SITE command as follows, which will
assure the receiving file will have the proper DCB attributes...
QUOTE SITE BLKSIZE=27998 LRECL=0 RECFM=U PRI=xxx SEC=xxx
TRACK
Of course you much change the space parameters as necessary.
Then,
prior to issuing the actual PUT command, issue these commands.
MODE B
EBCDIC
Mode B tells FTP to use block mode transfers.
The result is a file DFDSS likes!
++++++++++++++++++++++++++++++++++++++++
Jerry Whitteridge
Lead Systems Programmer
Safeway Inc.
925 951 4184
If you feel in control
you just aren't going fast enough.
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Steve Thompson
Sent: Friday, January 04, 2013 8:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: FTP "ERRORS" [was: RACF on an ADCD system]
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
"Email Firewall" made the following annotations.
------------------------------------------------------------------------------
Warning:
All e-mail sent to this address will be received by the corporate e-mail
system, and is subject to archival and review by someone other than the
recipient. This e-mail may contain proprietary information and is intended
only for the use of the intended recipient(s). If the reader of this message
is not the intended recipient(s), you are notified that you have received this
message in error and that any review, dissemination, distribution or copying of
this message is strictly prohibited. If you have received this message in
error, please notify the sender immediately.
==============================================================================
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
