Create a wlatin1 encoding XPT file in a UTF-8 encoding environment (CPORT)

[craig159753]

Hi, this is my first post so apologies if i do this wrong.

What i am trying to do is straight forward enough, I am working in two environments, one is using SAS EG with SAS 9.4 and has utf-8 encoding, the other is regular SAS 9.1.3 using wlatin1 encoding. I need to create an .XPT file (so a transport file) from a SAS data set, in the 9.4 environment but make sure the .XPT uses the wlatin encoding. I need this so i can read it in correctly in the SAS 9.1.3 environment, and make sure the extended characters are read correctly in the SAS 9.1.3 wlatin1 environment. So this is what I have so far.

This is my code in the SAS 9.4 UTF-8 environment

** My SAS Data set I want to convert to an XPT file;

data adsl (encoding = "wlatin1");

        set adam.adsl;

        ** Some extended characters;

        length ex_chars $20;

        if trt01pn = 1 then ex_chars = "é";

        if trt01pn = 3 then ex_chars = "µ";

        if trt01pn = 2 then ex_chars = "±";

run;

**====================================================================================;

** Where I want to XPT file to go;

libname xptfile xport "\\server\XPT\adslwlatin1_xpt.xpt" encoding = "wlatin1";

** Export XPT. File;

proc cport

        data = adsl

   file="\\server\XPT\adslwlatin1_xpt.xpt";

run;

Now here is my code to then convert this SAS 9.4 .XPT file into SAS 9.1.3 data set.

** XPT file location;

libname xptfile xport "\\server\XPT\adslutf8_xpt.xpt";

** SAS file location;

libname sasfile "\\server\XPT\SASFILE";

** Import XPT into SAS file;

proc cimport

   infile = xptfile

        library = sasfile;

run;

However since my 9.4 environment uses the UTF-8 encoding it seems to save the XPT. file as a UTF-8 encoded XPT file. Which in turn causes the XPT file once import into SAS 9.1.3 using the wlatin encoding to produce the following warning.

WARNING: The transport file is from an earlier SAS release, or 9.1.3 without the corresponding hotfix.  If this transport file contains non-English data, there may be problems importing national characters.  If problems do occur, the transport file will

Which I understand, and even though i define the XPT file location in SAS 9.4 to use the wlatin1 encoding, it still seems to save the XPT file as a UTF-8 encoded file.

So my question.

Is there anyway to create the XPT file in SAS 9.4 (which uses the UTF-8 encoding) but store the XPT file as a wlatin1 encoded file?

NOTE: This needs to be done with the CPORT procedure.

Thank you in advancedf-8

[SASKiwi]

I think you need to use a FILENAME statement with PROC CPORT:

filename xptfile "\\server\XPT\adslutf8_xpt.xpt" encoding = "wlatin1";

proc cport

        data = adsl

   file=xptfile;

run;

[craig159753]

No still produced the warning and the same issue with the extended characters. Since the transport file uses the encoding UTF-8 the extended characters in the data set in SAS 9.4 data set

é

µ

±

Transcode to double byte characters in the SAS 9.1.3 wlatin1 environment, and look like this in the data set

é

µ

ñ

[jakarman]

Base SAS(R) 9.4 Procedures Guide, Third Edition it is documented that behavior of cport/cimport.   Not being compatible in encodings. Even an import of latin1 into utf8 is failing.

Another is going form a newer to older release (regression) is not possible Base SAS(R) 9.4 Procedures Guide, Third Edition   The weirdest one was seeing it checking that including the fix-level.

[craig159753]

Thank you for the info, after having a read it looks like the encoding of the transport file is basically decided by the encoding setting of SAS session? In my case in SAS 9.4 uses the encoding utf-8, therefore so will my transport file

[jakarman]

Yep what you are seeing is the proof there has been utf-8 chars stored in the transportfile.   Those  é µ ± are not part of the 7bit ascii and must be get a mbcs representation in a utf8 session. That are those  à you are seeing.

That is getting into a disruption in many ways as 1 byte ^= 1 char   it now 1 char = 1-4 bytes.  The only way out van be using CEDA (sas7bdat) or SAS-connect (9.4 new functionality)  SAS(R) 9.4 Language Reference: Concepts, Fourth Edition 

[craig159753]

Hi, thanks again for your information. Yeah i understand the multi byte character sets (MBCS) issue.

The SAS CONNECT method you mentioned, does this still create XPT files? The main issue I need to send UTF-8 encoded XPT files to someone with a wlatin1 encoded environment, I can only seem to find that XPT files encoding is determine by my SAS session encoding option. Is there a way to change the SAS session encoding? 

[jakarman]

The SAS connect uses his own intermediate files. Moving and Accessing SAS(R) 9.4 Files, Second Edition  In the CEDA link also Socket mode (SAS/connect) is mentioned. The mentioned goal with CEDA is encoding issues.
The engine can be kept as a 9, the directory limitation is telling Windows and/or Unix. The exception is classic bound mainframe libraries, not your case.