BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
nhvdwalt
Barite | Level 11

Morning team,

 

I have a weird one this morning....

 

Last night we implemented hotfix Z29004 for SAS Access to Netezza 9.4_M3 on RHEL 6 to fix the error described in SAS Note http://support.sas.com/kb/58/291.html

 

This worked 100% and the row limits are now being used correctly in E Guide. Ok.

 

Then we started having transcoding errors when reading data from Netezza similar to what is descibed in this SAS Note:  http://support.sas.com/kb/59/905.html

 

Weird thing is, this very same hotfix should have FIXED the transcoding errors, now it seem to have INTRODUCED the issue.

 

Any ideas ?

1 ACCEPTED SOLUTION

Accepted Solutions
nhvdwalt
Barite | Level 11

Ah...thanks for reminding me....

 

Turns out, the LANG= variable on our RHEL 6 was set to UTF-8 whereas SAS and Netezza was set to LATIN.

 

But here is  the gotcha.....The RHEL 6 setting didn't change, so the question is how did it work before the hotfix ?? Turns out, with the Hotfix, SAS now enforces that the LANG= variable be correctly set, which is of course the right thing. Here is the real gotcha....This was not mentioned in the hotfix documentation, so we simply applied the hotfix without any further changes. We have asked SAS Tech Support to update the hotfix documentation with this info. So if your RHEL 6 is running UTF-8 by default and you apply this hotfix, it will trigger this condition.

View solution in original post

2 REPLIES 2
LinusH
Tourmaline | Level 20
Since your experiencing that this is connected to the hot fix, I think that SAS tech support is the way forward.
Data never sleeps
nhvdwalt
Barite | Level 11

Ah...thanks for reminding me....

 

Turns out, the LANG= variable on our RHEL 6 was set to UTF-8 whereas SAS and Netezza was set to LATIN.

 

But here is  the gotcha.....The RHEL 6 setting didn't change, so the question is how did it work before the hotfix ?? Turns out, with the Hotfix, SAS now enforces that the LANG= variable be correctly set, which is of course the right thing. Here is the real gotcha....This was not mentioned in the hotfix documentation, so we simply applied the hotfix without any further changes. We have asked SAS Tech Support to update the hotfix documentation with this info. So if your RHEL 6 is running UTF-8 by default and you apply this hotfix, it will trigger this condition.

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 2 replies
  • 1093 views
  • 3 likes
  • 2 in conversation