FTP transportability

[McKown, John]

I think that I'll summarize what I have gotten from all this back and
forth about ftp'ing z/OS datasets.

1) If it is a PDS, then use XMIT to "flatten" it to a sequential format.
2) If it is VSAM, do an EXPORT TEMPORARY to "flatten" it to a sequential
format.
3) If it is a sequential file (possibly even including the two above
"flattened" outputs), use TRSMAIN to make it FB.
4) Do a BINary transfer.

On the far end, reverse the process. Can we all agree on this and go on
to other things now? Thank you so very much.

Note - this does not address the case where a non z/OS system will want
to be able to process the data. In that case, it will likely require a
case-by-case assessment of what would be best.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential. It is for intended addressee(s) only. If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense. If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Kenneth E Tomiak]

The only change I have is: I only use TRSMAIN if it is going to IBM. Otherwise
transmit and receive will work for me on more z/OS systems without the need
to try and upload TRSMAIN. (I used to have JCL to pull it straight from IBM
but they are leaning towards making you click an I AGREE button on so many
pages I do not recall if it works.) Transmit always gives me an FB 80
sequential BINary file so I do not need an extra step with trsmain. And
typically the only file I give IBM is an SVCDUMP.

[Kenneth E Tomiak]

From my reading in TSO/E Customization, TRANSMIT makes the call to
IEBCOPY if you process a DSORG=PO type of dataset and Access Method
Services REPRO if you process a VSAM dataset. No need for an extra step to
flatten VSAM. Sounds like something to try after I finish rewriting my PC DOS
7.0 REXX receive code.

[Bob Rutledge]

Where did you see this? I only found...

5.13.1.1.3 Transmitting unsupported data types

You can use TRANSMIT to send sequential or partitioned data sets with record
formats of F, FS, FB, FBS, V, VB, VBS, and U. Data sets with machine
and ASA print-control characters are also supported. Data sets with keys or
labels, and ISAM and VSAM data sets are not. RECEIVE can process data
from TRANSMIT and PROFS.

...in the z/OS 1.8 book.

Bob

Kenneth E Tomiak wrote:
>>From my reading in TSO/E Customization, TRANSMIT makes the call to
> IEBCOPY if you process a DSORG=PO type of dataset and Access Method
> Services REPRO if you process a VSAM dataset. No need for an extra step to
> flatten VSAM. Sounds like something to try after I finish rewriting my PC DOS
> 7.0 REXX receive code.

----------------------------------------------------------------------

[Kenneth E Tomiak]

TRANSMIT will not work on VSAM and yet the TSO/E Customization maual
shows it supports a DSORG for VSAM. The bad conenction I made was reading
they support VSAM as a dsorg and they name AMSCIPHR for calling AMS to
deecrypt a file. How a DSORG of VSAM would ever get in a transmit file if
TRANSMIT does not support it is beyond me. Likely yet-another-bug in the
manuals. I have been finding lots of them lately. Perhaps if you use the
ENCIPHER keyword. I am not ready to try that. They did remove ISAM as a
DSORG.

[Josef Berger]

If data are transported between z/OS systems, we are using TYPE E and = MODE
B instead BIN because Structure of records isn't lost. If we did put for
example a PDS/PDSE Dataset with BINary the ISPF statististic fields = like
version changed and so on was lost in the directory.

For a transferre of a large PDS/PDSE dataset, we prefer DFDSS unload on the
local site, ftp it to the target system, put a reload job to the target
system and get output back. Because this is more than one ftp step, we have
written a REXX which creates the DFDSS unload / reload and FTP control
cards and executes it after the generation step.

Regards

Jose

"McKown, John" <John....@ibm-main.lst> schrieb im Newsbeitrag
news:80ED1590A931EE45BAE1...@UICNRHECHP6.uicnrh.dom...