About jklaverstijn

jklaverstijn · ‎03-31-2022

Thanks for the link Greg. I will point our proxy people to this resource. Looks like it must be possible given a certain amount of experimentation and determination. Will report back once we have result. Cheers, - Jan.

jklaverstijn · ‎03-30-2022

Hi all, We have users that want to use EG to connect to a Viya compute server. While advertising StudioV there are still EG strongholds in our organization. In order to avoid them all connecting to the same compute host (we have anywhere between 2 and 5 depending on the deployment size) we want to utilize a load-balancer. For now (we hope to get an F5 later this year) HAProxy seems a good choice for this. But we are struggling to get the connections "sticky" enough. As long as one uses a single EG session there is no problem. But having multiple EG connections simultaneously we get connection errors ("connection lost") when switching between the EG's. This appears to be caused by HAProxy sending a request from session A to the host assigned to session B. We can probably solve this but at the cost of tying a client pc to always the same compute host. Something we like to avoid. Maybe HAProxy is too much designed for HTTP and TCP has come as an afterthought? Has anyone been successful in configuring TCP (Layer4) stickiness in HAProxy for this scenario? Would you be willing to share your config? Kind regards, - Jan.

jklaverstijn · ‎02-18-2022

I have no detailed info on your environment. Depending on that, this can work. Consider employing Kerberos or the like for single-signon. This can allow your to authenticate in such a way that this will also allow access to other resources such as databases. There is some setup hardship and knowledge involved but once you have it going there is no beating this. It can work for both Studio and EG users. Personal Login Manager will be a thing of the past. And your users will thank you for that.

jklaverstijn · ‎05-26-2021

I 100% agree with @SASKiwi that you should first and foremost lock up the data and not the tools to access them. I also respectfully disagree with @Kurt_Bremser. A healthy dose of mistrust towards users is the start of any security initiative. Working for a government institution with highly sensitive data we make distrusting our users the foundation of every system design. But we do give them SAS as much as possible. That said, I can imagine that you would even want to be careful with what users can do with the data they are privileged to access. Being allowed to run a a report does not mean one should be allowed to export the underlying data and send them off in an email. That's where SAS offers the LOCKDOWN option. Have a look at that. It may be just what yo need or be too much. That depends. What we often do is to limit users to the use of VDI's . These virtual desktops do not have any networked connection to the outside world so exporting data and even copy/paste does not work. There are limits to what one can achieve but VDI's are very effective. Hope this helps, - Jan.

jklaverstijn · ‎05-25-2021

If you want to collect the historical data from LSF jobs and flows you can read the files that LSF keeps. There are a few in the LSF directory (jobs) and the process manager directory (flows). The structure of these files is documented by IBM. The ones of most interest are: .../lsf/work/sas_cluster/logdir/lsb.events https://www.ibm.com/support/knowledgecenter/en/SSWRJV_10.1.0/lsf_config_ref/lsb.events.5.html .../lsf/work/sas_cluster/logdir/lsb.acct https://www.ibm.com/support/knowledgecenter/en/SSWRJV_10.1.0/lsf_config_ref/lsb.acct.5.html pm/work/history/history.log.* These files contain the data that you get from the bjobs, bhist and jhist commands. Depending on how you configured LSF these commands (and the Flowmanager application) show only recent history. This approach allows you to keep the info for an indefinite amount of time. Let me also point you to the EOM Job Monitor that builds a database of your job and flow execution and has a effective flow-centric web interface.

jklaverstijn · ‎05-25-2021

This looks like you crated a file wirth DOS line terminators (cariage return+linefeed) and looking at it in a Unix/Linux environment. Linux and UNIX consider the linefeed as the terminator, regarding and showing the carriage return (Ctrl-M) as part of your data. We do not now how you create the file but possibly a filename statement is involved. In that case you can use the TERMSTR option to influence the choice of line terminator. So determining on your situation the ^M may be a problem or not. Depending on what your plan is with the file if may be ok or it needs to go. SAS leaves it to you. Hope this helps, - Jan./

jklaverstijn · ‎04-28-2021

It is no small decision to change the encoding for a deployment that is servicing a large population and has many SAS datasets. The impact is considerable. You can however start a separate SAS session in its own ad-hoc encoding. I have run into the same issue, largely due to DI Studio jobs with "Em dashes" in descriptions and user written code. I have taken a laborious detour by creating the datasets in a UTF-8 session, spitting them out into CSV files and scanning them for "illegal" symbols like the Em dash and the curly quotation marks you get from MS Office products. You can then weed them out of your metadata. That may be more of a challenge if your metadata originates in an external source like Active Directory. What realy bugged me here is that this can easily happen when you use a Windows client (DI Studio, Management Console) but your SAS server is on Linux or Unix. Any XML based interface like the macros you mention can then trip over them when encoding is anything other than UTF-8. One thing to be aware of is that, despite popular belief, WLATIN1 on Windows is not the same as LATIN1 (aka ISO-8859-1) on Linux/Unix. SAS is somewhat lenient towards those differences but you still run into issues as the one you describe. I highly recommend UTF-8 for new SAS deployments but warn against just flipping the switch on an existing one. You will end up in a world of hurt if you do. Hope this helps, - Jan.

jklaverstijn · ‎04-28-2021

Hi @TBarker Good news! Many thanks for the heads up.We had postponed our M7 upgrade and will now be able to use the tool in our next attempt. Regards, - Jan.

jklaverstijn · ‎04-13-2021

That will work. Note that the dataset will have to be recreated; you cannot change the length of variables without that. Also, the max length of a char is $32767 and not 6000. If you have 100+ of those the disk space requirements can rapidly explode and burden your I/O subsystem. It may become unwieldy. Consider adding COMPRESS=YES to deal with some of the downsides of a large amount of long characters, especially if you have a fair percentage of missing values. Another approach could be to reconsider the data modelling. A table with a large amount of character variables can often be transposed into a version with one long char plus an identifying variable. Of course that depends entirely on the case at hand. Hope this helps, -- Jan.

jklaverstijn · ‎03-04-2021

Thanks Kurt, I opened a track and will update this thread with its conclusions. I will keep you posted on how the track fares. Regards, - Jan.

jklaverstijn · ‎03-04-2021

Hi Kurt, If the Euro sign is in the Latin1 set then it is not transcoded properly by SAS (or ODBC or whatever is in the chain). We take data from SQL Server and Euro signs are re[pl;ced with the SUB character. When choosing Latin9 it is not. I agree with your statement about a consistent approach for encoding. In this company that would almost certainly mean UTF-8. And that is not something that can be achived on the premise of this migration issue. We must keep this small and focused. Also consider this: I create a DIS job in Windows containing a euro sign, some smart quotes and m-dash in its description. I make an export and import that in AIX. When setting encoding=latin1 I can succesfully deploy the code for that job (albeit with substituted characters). However, when I set encoding=latin9, I get: So there is a difference between the two that is not obviously explained by the differences in their actual definition. Maybe a track with SAS Support is in order/

jklaverstijn · ‎03-03-2021

Hi all, Sorry for the long intro. But it needs to be explained. We are in the process of migrating a SAS Grid environment from Windows 9.4M1 to AIX 9.4M6. Initially it was considered a "natural" choice to let the encoding go from WLATIN1 on Windows to LATIN1 on AIX. And yes, UTF-8 was considered and dropped; let's keep that out of the discussion please. So Latin1 did it's job just fine until trouble arose when we found out that it does not contain the Euro sign. Lots of data is stored in SQL Server and occurences of the "€" sign were silently transcoded into a generic currency symbol "¤". And being a Dutch insurance company this is a big deal. So after careful consideration and testing we changed to Latin9, advertised as "Latin1 but with the Euro sign". But now we get into a whole new area of problems. Existing occurences of all sorts of the more obscure WLATIN1 characters like the m-dash and MSOffice's "smart quotes" are now leading to errors when creating XML. Main affected area is the AD sync where for example the %mduextr macro extracts metadata. This now fails with the following message: ERROR: Failed to transcode data from U_UTF8_CE to U_LATIN9_CE encoding because it contained characters which are not supported by your SAS session encoding. Please review your encoding= and locale= SAS system options to ensure that they can accommodate This did not occur when we used Latin1! We tracked this down to metadata of users where phone numbers were entered using copy/paste from Word and Excel that introduced these. Probably in part starting in user management in active directory itself and then being imported. Another occurence was an "em-dash" in the name of a metadata library. But we also have a job that scans the metadata of DI Studio jobs which runs in similar issues with descriptions of steps and even user written code that contains these characters that are not present in the Latin9 encoding. This meant the problem runs so deep now that we cannot just replace a few characters. The easy way out seems going back to Latin1. But hey, that pesky Euro sign is definitely a big deal. It seems to revolve around XML generation from proc metadata. So my main questions are: 1) Has anyone seen this and found a way to fix it? 2) Why is the impact of the change from Latin1 to Latin9 so big?

jklaverstijn · ‎12-22-2020

Hi @briankinnebrew, On behalf of all of us AIX Power9 peeps: will we be able to benefit from this at some point in time? Regards, -- Jan.

jklaverstijn · ‎11-26-2020

Ah yes I see. Thanks for pointing that out Kurt. I will make a correction.

jklaverstijn · ‎11-26-2020

Don't think that switching from LATIN to UTF-8 is a matter of simply changing the encoding of your SAS session! Your existing datasets would still be LATIN. This is almost as if your data is from a different operating system. You would run into all sorts of limitations and issues.Some examples: Copying a table that has the name "André" in a CHAR(5) would no longer fit in the UTF-8 world, leading to truncation and error messages (real world example). The function call length("André)" would give different results between LATIN and UTF-8. Therefore the KLENGTH() function (and more generally, a whole slew of K*() functions) are available.to deal with the now new discrepancy between length in bytes and length in characters. A code overhaul could be in order. RDBM's can differ in how they calculate string length (bytes or characters). For example if you extract data from Teradata you can get triple the length in bytes for character columns. So a Teradata VARCHAR(3) would yield a SAS $9. Loading that back into Teradata would give a VARCHAR(9) which can lead to a $27. Do that a couple of times and you can see the problem escalate. So, the gist of my response is: don't underestimate the impact of changing your encoding. It is at best a migration project and not a mere configuration change. That migration may also be your best approach, depending on your reliance on data from UTF encoded data. Hope this helps, -- Jan.

Online Status	Offline
Date Last Visited	‎09-22-2025 12:07 PM

Re: Why does SAS randomly report "Library WORK does not exist" during ...

Empty Web App Servers

Re: Email notifications from subflows

Re: Email notifications from subflows

Re: Automating SAS Package deployment using Import/Export Batch Tool

Re: Automating SAS Package deployment using Import/Export Batch Tool

Email notifications from subflows

Re: Wolfensäs: The FPS game that was written in SAS

Re: SAS Upgrade from 9.4 M7 to 9.4 M8 failing

Re: How to attach a file from a server in SAS Email

Re: Before you update to RHEL 8.8, please read.....

Re: Reference column type in data step OR suppress invalid numeric dat...

Re: How to set the umask for CAS?

Re: Convert Character ISO datetime into datatime

Re: SAS EG Stored Process wont update table

Re: Email notifications from subflows

Re: SAS Enterprise Guide to point to Unicode SAS

Re: SAS Upgrade from 9.4 M7 to 9.4 M8 failing

Re: Which element of the architecture effectively sends an e-mail when...

Re: How to set the umask for CAS?

Re: Sticky connections to Viya compute server via HAProxy

Sticky connections to Viya compute server via HAProxy

Re: Personal Login Manager combined with SAS Studio in SAS Grid 9.4

Re: Control access for users scripts

Re: Looking for LSF detailed flow information Linux

Re: How to remove ^M Junk values while converting sas dataset to flat ...

Re: Security Report with SAS-Autocall Macros mdsec**

Re: The SAS 9 Content Assessment Tool

Re: How to increase the length of character value

Re: Troubles when choosing between Latin1 to Latin9

Re: Troubles when choosing between Latin1 to Latin9

Troubles when choosing between Latin1 to Latin9

Re: The SAS 9 Content Assessment Tool

Re: Format large number?

Re: Encoding trouble UTF-8 vs LATIN1 with SAS ACCESS TO ODBC Configura...

SAS Global Forum 2017

SAS Global Forum 2018

SAS Global Forum 2016