Zip SAS Data on MVS

[OS2Rules]

Hi all:

Another quick question - how do I zip a SAS file on a z/OS (MVS) mainframe so I can FTP it to a local server?

I've read some of the other threads on this and they all deal with zipping or unzipping the file locally.

I want to see if zipping the file first will reduce the time it takes to download (it's pretty big).

I would rather do it in my CONNECT session, than having to run a MVS batch job that runs PKZIP on the mainframe - and then downloading the resulting file.

Thanks in advance.

[sbb]

Your SAS file will need to be converted go CEDA-format. Then it can be "moved" to another OS platform, as required. Check the SAS companion documentation for creating a "transport format" file which then can be zipped, then FTP'd to a foreign-host, all in one z/OS MVS batch jobstream.

Scott Barry
SBBWorks, Inc.

move sas data different os site:sas.com

transport format ceda site:sas.com

[OS2Rules]

Scott:

I'm really hoping that I don't need to unload the SAS data to a transportable format - I would like to zip the SAS file and transmit it to my local machine. My manual for zip for z/OS says that the recieved file will be compatible no matter what platform it is sent to - I'm hoping this isn't just smoke and mirrors.

If I can run a "X" command on the local machine to unzip a file, I would just like the syntax for a similar command on the mainframe to do the zip ... maybe invoke REXX and have it run the zip ??

[sbb]

SAS data libraries are not always cross-environment compatible -- you will want/need to read the companion documentation for the details; it has to do with EBCDIC and ASCII conversion.

You can't expect to just zip-up a mainframe SAS data library, transport it in binary to another different OS platform, unzip it and expect to be able to read / process the data library as-is.

Your ZIP documentation is not considering that this is an "application database" format, not a sequential file. I believe you are reading too much into the statement, as well -- I believe it means that a "zip archive" can be moved to another OS platform, unzipped and used there.

Scott Barry
SBBWorks, Inc.

[Peter_C]

how about defining a filename in your SAS session with the ddname that would be used by your z/OS zip program for the output from zip and for the input ddname for zip point at the mainframne file you want to compress. Then instead of x zip, submit
proc zip ;
run;
and replace zip in that proc statement with the executable name for your mainframe ZIP.
Oh, forgot to suggest also, make the filename for the output from zip use the ftp server on the receiving machine.

[OS2Rules]

Scott and Peter:

Thanks for all the information.

I finally got around to doing some experimentation and found out that my source regarding whether the zip file is transportable was lying (!).

I used the MVS version of PKZIP to zip a SAS dataset and then sent both the original and the zipped file to my PC. The original was about 15x larger than the zipped version. I couldn't read the zipped copy at all - couldn't even unzip it (it was a "bad archive").

Lesson learned. Thanks again.

[Peter_C]

I'm surprised the zip (delivered with a binary transfer) failed to be recognized.

There best alternative I would recommend is SAS/Connect which uses the cport transport format which is compressed. The method also overcomes the different architectures.
If that is not available, you could knock something up with filename statements using tcpip ports - then run proc cport on the mainframe into the open port that is being read by proc cimport on the pc.

peterC

[OS2Rules]

To make this problem even more complicated ...

I added a step on the mainframe to create a "transportable" format file using PROC CPORT. This file I then zipped and sent to the local machine (in binary). Once there I was able to unzip the file, but when I tried to rebuild the SAS dataset with a PROC CIMPORT, I get:

ERROR: Unrecognized or unsupported transport file format.

I'm thinking that the original file is EBCDIC (the transport file), and I need to tell zip on the local machine to unzip the file to ASCII (??).

[SASKiwi]

I suggest you repeat your test, but don't zip/unzip the file. If this works then it is the zip/unzip causing the problem. If it doesn't work then you can conclude that your transport file is not correct.

BTW a transport file on MVS has to have certain file characteristics (eg RECFM = F, LRECL = 80, BLKSIZE = ??). Check the documentation as I am quoting this from memory. It is my understanding that a transport file is always created in ASCII regardless of the platform it is created on, hence the need for the binary transfer.

[sbb]

As suggested, reading the available DOC on the topic goes a long way.

Scott Barry
SBBWorks, Inc.

[OS2Rules]

After much hair-pulling and griding of teeth, I think I have it working.

Firstly, as in most cases, it came down to a teeny-weeny parameter in the MVS PKzip - I needed to do a "binary" compress rather than a "text" compress on the mainframe.

So now the process goes:
1)export the SAS table I want to a transport format (PROC CPORT)
2)Zip this file on the mainframe - in binary
3)switch to my "local" system and download the zipped file (PROC DOWNLOAD) in CONNECT - again - in binary
4)unzip the file locally
5)import that file back into a SAS table (PROC CIMPORT)
6)pat myself on the back for a complex solution to a simple problem!

Thanks to all for the help.