When you join two DBMS tables that contain a TRANSCODE=NO field, the setting on those variables might be changed to YES in the results of the query. Incorrect data might result when the data is moved from one operating system to another.

The following examples illustrate cases of incorrect results that might occur when the TRANSCODE field has been changed:

First Example (normal character column)

• A column contains the alphanumerical value '1234567890'. This is coded in EBCDIC as 'F1F2F3F4F5F6F7F8F9F0'x.
• If the value is transferred to a Windows operating environment with TRANSCODE=YES, the value '1234567890' stays but it is now (trans)coded in LATIN9 as '31323334353637383930'x.
• If the value is transferred to a Windows system with TRANSCODE=NO, the hexadecimal value 'F1F2F3F4F5F6F7F8F9F0'x stays, which in LATIN9 now means '??????????'.

Second Example (binaryKey)

• A column contains the binary data 'B7E34C4240F1'x. This would appear as '1/4T<? 1' in a z/OS operating environment.
• If the value is transferred to Windows with TRANSCODE=YES, the binaryKey is corrupted, as SAS tries to maintain the readable string '1/4T<? 1', but changes the hexadecimal value to 'BC543CE22031'x.
• For a binaryKey, you need to set TRANSCODE=NO to maintain the hexKey and not worry about the resulting.

To work around this issue, create SAS^® data sets containing the DBMS tables and do the join operation in SAS.

Click the Hot Fix tab in this note to access the hot fix for this issue.

Operating System and Release Information

A fix for this issue for Base SAS 9.3_M2 is available at: