MVSFORUMS.com

[jfdutcher]

I run a 'JAR' command in z/OS to unzip an archive member retrieved from a web URL. The unzipped file size agrees precisely with the size of the same file archive member unzipped if done in Windows.
I run a JCL executing the TSO/E utility and use 'many' variations of 'OPUT/OGET to write the unzipped file to the MVS side .....(text, binary, convert(yes/no etc.)
but none deliver a 'useable' (readable by ordinary Cobol pgm.) result.

Yet, if I bring it over as 'binary'....then download it to Win 2000 using our
QVS3270 terminal emulator...then upload it back to MVS....a magical transformation has occurred....it now has the 'expected' characteristics,
variable blocked records that respect CRLF.

Is there no aspect of OPUT/OGET that can bring over the file with the same characteristics it has after downlaod/upload ........directly ?
I am believing that if the 'JAR' command was 'not' really the equivalent
of WinZip 'unzip' command....I would not get exactly equal file sizes for output....nor would the download/upload finally create the 'useable' file
I would prefer to get without those two steps.l
_________________
John F. Dutcher, Principal Consultant, Keane, Inc.

[semigeezer]

The file as unpacked is in ASCII or UTF-8 or some other encoding. The upload does the conversion to EBCDIC. You can use iconv in the shell to do the translation at the host. For example:

[jexcellus]

[semigeezer]

I always wondered how to handle that and your question prompted me to look it up. I once wrote an ISPF browse interface to browse ASCII files on MVS directly using the BRIF service. It was not really a trivial exercise.