10-27-2016 01:38 AM
Transferring data sets to the mainframe costs too much as the translation to EBCDIC is done when the file arrives.
Is there a way to have the *sending* SAS session do the translation work?
I tried using OUTREP= option to create an EBCDIC table on the Windows machine, but I suspect it is translated back to ASCII in order to be read, before being sent to the mainframe, where it is translated again to EBCDIC.
Any better idea?
10-27-2016 03:08 AM
As far as I can interpret the reference documentation, outrep= creates a table in the target format; you would then have to transfer the dataset file in binary mode to the z/OS system, using any suitable tool (FTP, ....).
What do you mean by "costs too much"? Are you being charged on the mainframe per CPU ticks, or is the SAS performance on the MF so dismal?
10-27-2016 04:52 PM
Z/OS would not know what to do with a *.sas7bdat file, and it would require further processing. No? How would this work?
Yes the financial cost is too high, the speed is fine.
@LinusH I'll try.
Thank you all.
10-27-2016 05:25 PM
OK if its a SAS dataset and you are moving it from one OS to another you have at least two choices:
10-27-2016 08:51 PM
> SAS/CONNECT if installed at both ends can handle the translation transparently without you doing anything.
"without you doing anything" is the sore point here. The receiving host translates the data to its session's encoding format. And this is expensive.
I want the translation to happen on the sending host. A binary transfer of an EBCDIC flat file created on windows would allow this, but there would need to be a data step to infile/input it and therefore no gains, but increased complexity. Same thing with a transport file, which would have to be cimported.
10-27-2016 09:38 PM
Mmm. Nothing seems to work.
Transferring cport files with proc up/download is also an issue, and the documentation only mentions NFS or FTP as valid transfer methods (https://support.sas.com/documentation/cdl/en/movefile/63050/PDF/default/movefile.pdf page 22) which is very silly.
I guess I'll open a sasware ballot idea entry for both these SAS/CONNECT limitations.
I reckon the most logical way would be to use:
rsubmit WINBOX; proc download data =TABLE out =TABLE(encoding='open_ed-1047' outrep=MVS_32)
status=no ; run; endrsubmit;
10-28-2016 02:42 AM
IIRC, a SAS library on z/OS is a partitioned mainframe data set where the SAS datasets are members. The format of the PD defines how members are stored in it.
Transfers should be done like this from the MF side:
- declare and create the PD for the catalog (take parameters like blocksize etc from existing SAS libraries)
(assume the file is called XXXX.YYYY.ZZZZ in the catalog)
- do an ftp from the MF to the UNIX/Windows:
get opensystemdata.sas7bdat 'XXXX.YYYY.ZZZZ(DATA)' (replace
This could(!) end up with a dataset DATA in library LIB if you issued
libname lib "'XXXX.YYYY.ZZZZ'";
on the mainframe.
10-28-2016 03:50 AM
I haven't tried ftp as the windows server doesn't have an ftp service. But you are right I need to try.
10-28-2016 03:52 AM
10-28-2016 03:58 AM
I wonder what the difference is between a binary transfer with ftp and sas/connect.
10-28-2016 04:06 AM
I guess that SAS/CONNECT uses a common format for the transfer and leaves the conversions to the endpoints. Especially the conversion to/from EBCDIC will happen on the MF.
Since a binary FTP really only shuffles bytes from A to B, it will be the least CPU-intensive method. If it works as intended in your case.
10-28-2016 05:08 AM
10-28-2016 05:33 AM
What I meant was that if you can do the conversion to a z/OS SAS dataset on the Windows/UNIX side, and then use just the mainframe's FTP client to transfer, you can offload the conversion CPU ticks to the open system side.
Although SAS/CONNECT will use a binary transfer in between the hosts, the conversion to EBCDIC will surely not happen on the Windows/UNIX side, instead it will be done on z/OS.