Cross-Architecture Access

Implications of Data Translation

Translation of Data at the Client and the Server

In SAS/SHARE, translation of numeric variables occurs when the server machine and the client machine represent floating-point numbers differently. For character variables, translation occurs when their character representations differ. Values are dynamically translated directly from the source representation to the target representation; they do not pass through transport format. Translation occurs both when data flows from the server to the client and when it flows from the client to the server. Therefore, data that flows across architectures from a server to a client and is then sent back to the server is translated twice.

For all operating environments that SAS/SHARE runs on, the REMOTE engine performs all data translations that are necessary in order to converse with the server. The REMOTE engine translates outgoing data to the server format, and translates incoming data from the server to its own format. The administrative procedure, PROC OPERATE, works in the same way.

Note: For all SAS/SHARE clients other than SAS sessions, such as the SAS ODBC driver, data translation occurs on the server, not on the client. [cautionend]

Translation of Floating-Point Numbers between Computers

Loss of Numeric Precision and Magnitude

If you move SAS data between a client and a server session that run on computers that have different architectures, numeric precision or magnitude can be lost. Precision can be lost when the data value in the source representation contains more significant digits than the target representation can store. A loss of magnitude results when data values exceed the range of values that an operating environment can store.

For complete details about how SAS stores numeric values, see SAS Language Reference: Concepts.

Avoiding Loss of Precision

To avoid loss of precision, do not store numeric values in short variables. Instead, store numeric values using longer numeric variables (up to 8 bytes) according to the number of significant digits that the target representation can store.

Significance of Loss of Magnitude

When you lose magnitude, SAS produces the following warning:

WARNING:  The magnitude of at least one numeric value 
was decreased to the maximum the target representation allows,
due to representation conversion.

A loss of magnitude is unlikely in many applications, but if you have data with extremely large values or extremely small fractions, you might experience a loss of magnitude during cross-architecture access. When you lose magnitude, SAS changes the values that are out of range to the maximum or minimum value that the operating environment can represent.

Approximate Value Ranges by Operating Environment
Operating Environment	Minimum Value	Maximum Value
OpenVMS	2.3E-308	1.8E+308
UNIX	2.3E-308	1.8E+308
Windows	2.3E-308	1.8E+308
z/OS	5.4E-79	7.2E+75

Example

You create a data set under UNIX that contains the value 8.93323E+105 . If you copy the file to a z/OS operating environment, magnitude is lost and the value changes to 7.23701E+75 , which is the maximum value that z/OS can represent.

Character-Translation Tables

Note: The use of translation tables is relevant only when you use the following:

SAS 8 and SAS 9.2 cross-release access
thin client and SAS 9.2 server access

The tables that are used for character translation in SAS/SHARE are stored in SAS catalog entries of type TRANTAB. Each of these catalog entries contains two translation tables. The first table is for import translation, and the second table is for export conversion. For example, the EBCDIC/ASCII-OEM translation entry under z/OS contains an import table for ASCII-OEM to EBCDIC translation and an export table for EBCDIC to ASCII-OEM translation.

Translation Tables and Catalog Entry Names
Translation Table Set		Catalog Entry Name
EBCDIC/ASCII-ISO		_0000030
EBCDIC/ASCII-ANSI		_0000060
EBCDIC/ASCII-OEM		_00000A0
EBCDIC/ASCII-MAC		_0000120
ASCII-ISO/ASCII-ANSI		_0000050
ASCII-ISO/ASCII-OEM		_0000090
ASCII-ISO/ASCII-MAC		_0000110
ASCII-ANSI/ASCII-OEM		_00000C0
ASCII-ANSI/ASCII-MAC		_0000140
ASCII-OEM/ASCII-MAC		_0000180

Character-translation catalog entries are stored in the SASUSER.PROFILE and SASHELP.HOST catalogs. The translation process locates a specific translation entry by first searching the SASUSER.PROFILE catalog and then searching the SASHELP.HOST catalog.

The client's execution of the REMOTE engine and the client's translation tables are responsible for all data translations that occur between a SAS/SHARE client and a server. However, the SAS/SHARE server is responsible for the data translations that occur between that server and all SAS/SHARE clients other than SAS sessions.

SAS site administrators can use the TRANTAB procedure to replace or update the translation tables. For details, see the TRANTAB procedure and the TRANTAB= system option in the SAS National Language Support (NLS): User's Guide.

CAUTION:: Do not attempt to update a translation table in a client session while accessing the SAS/SHARE server that the translation table will be applied against.
You cannot ensure that the new version of the table will be used for subsequent translations.

Data Translation Considerations

Data translation in SAS/SHARE has some implications that users need to consider. For example, suppose you assign two SAS libraries, ROO and ZOO, through a server on an operating environment that has an architecture that is different from your machine. You copy the data sets that are contained in ROO to ZOO:

proc copy in=roo out=zoo mt=data;
run;

The contents of the copied data sets in ZOO are not guaranteed to be identical to the contents of the original data sets in ROO because the data sets in ZOO have been translated twice. First, the data is translated from server representation to client representation, then from client representation back to server representation.

As another example, suppose you are using the FSEDIT procedure to edit a data set across architectures. You enter a DUP command and then modify the variable X before saving the new record. You might find that, other than the value of the variable X, the new record is not identical to the old record. The original values of the duplicated record have been translated twice, from server-machine format to client-machine format and back to server-machine format. The new value that was entered for the variable X has been translated only one time, from user-machine format to server-machine format.

Note: When editing or updating a data set across architectures by using the FSEDIT procedure, the FSVIEW procedure, or the MODIFY statement in the DATA step, any variables that are not updated in an updated observation are exempt from translation and will be unaltered. [cautionend]

Problems Parsing Numeric Data in a Cross-Architecture Environment

SAS code (keywords and data) are submitted for execution as text. During parsing, numeric data is converted to the floating-point representation that is used by the operating environment and computer. For UNIX and Windows, numeric data is represented in IEEE floating-point format. For z/OS, numeric data is represented in IBM floating-point format.

When using SAS/CONNECT and Remote Library Services to process numeric data in a cross-architecture client/server session, you might get unexpected, but logical, results.

Consider a scenario in which a SAS/CONNECT client session under Windows accesses a server session under z/OS. In this code example, the value -6.14, which is stored in a data set, is used in a WHERE clause. This number cannot be represented exactly in either IEEE or IBM floating-point formats because -6.14 is a repeating decimal, in binary. Regardless of whether -6.14 is stored under Windows or z/OS, its representation is imprecise.

 /* Start a server session on z/OS */
options comamid=tcp remote=zos;
filename rlink "c:\sas\v9\connect\saslink\tcptso.scr";
signon;

/* The following code is remotely submitted to the server session  */
/* under z/OS. The text is passed to z/OS and is parsed on z/OS. */
/* When the text "-6.14" is parsed on z/OS, the resulting value  */
/* is stored on z/OS in IBM floating-point format.               */
rsubmit; 1 
   data sasuser.test_4;
   format RUE_H comma18.2;
   RUE_H= -6.14; output; 
   RUE_H= -6.14; output;
   RUE_H= -6.14; output;
   RUE_H= -6.14; output;
   run;
endrsubmit;

/* The following code assigns a server library on z/OS.         */

libname test1 server=sdczos slibref=sasuser;

/* The following statements are parsed in the client session    */
/* on Windows, and the results are stored in IEEE format.       */
/* in the client session in IEEE format.                        */

/* You might expect the following WHERE clause to return zero   */
/* records because the expression resolves to 0.                */
/* However, this code execution returns 4.                      */
proc sql; 2 
   create table xx2 as
   select RUH_H
   from test1.test_4
   where RUE_H < -6.14 3 ;
quit;

Parsing the string "-6.14" on z/OS produces a binary IBM representation of -6.14.

Parsing the string "-6.14" on Windows produces a binary IEEE representation of -6.14.

The WHERE clause, which contains the Windows binary IEEE value, is sent to z/OS via RLS, the IEEE representation of -6.14 is converted to its closest binary IBM equivalent. However, when an IEEE binary representation of -6.14 is converted into IBM format, the result is different from the IBM binary value that was obtained by parsing and converting the string on z/OS.

The clause where RUE_H < -6.14 finds four observations because the binary IBM value that is obtained by converting the binary IEEE value is slightly smaller than the binary IBM value that was stored in the data set when "-6.14" was originally parsed. Although you might expect the WHERE clause to return no observations, it returns four observations because of the lack of precision that occurs when converting data across operating environments.

To avoid cross-architecture problems, you could change the code so that PROC SQL is remotely submitted to execute in the server session on z/OS. The text value, "-6.14", in the WHERE clause would be parsed and converted on z/OS and would result in the same binary representation that was used in the original data set, which was also parsed and converted in the server session on z/OS. Therefore, the WHERE clause would return no observations, as expected.

rsubmit; 
proc sql;
   create table xx2 as
   select RUH_H
   from test1.test_4
   where RUE_H < -6.14 ;
quit;
endrsubmit;

When using SAS/CONNECT and RLS to process floating-point numbers in a cross-architecture environment, ensure that all statements are parsed in the same session, either the client or the server.

Top of Page