SAS AIX to LINUX platform migration questions

[pmaturi83]

Hello -

We started a project to convert existing SAS platform from AIX (lpar) to RHEL VM. Here are the details of versions and questions.

AIX Server: It is on SAS 9.4 M5

RHEL Server: To be on SAS 9.4 M6

Questions:

1) My AIX server is with locale setting as "C" and RHEL server is with locale "en_US.UTF-8". What is the impact for this change? Installation and configuration on RHEL completed and I captured this change late in game.  Wondering if it causes any issues with performance and adverse outputs for business users.

2) Data sets, does it require any conversion to datasets? We are planning to do copy of datasets stored on AIX server using back up strategy or OS platform team. Content is huge and it will be in TBs

3) Any recommendations for SAS running on RHEL VM

4) Do I need to consider any thing else. Any experiences or lessons learnt on these kind of activities?

[SASKiwi]

Checking out the Migration Focus area is a good starting point: https://support.sas.com/rnd/migration/

You can use the Compatibility Calculator to identify what SAS content needs conversion. I suspect you will need to convert SAS data as you are changing OSs.A good way of moving SAS data is to use SAS/CONNECT which allows you to copy whole SAS libraries with just one statement and do any necessary conversion at the same time.

Don't forget about migration of metadata as well.

[AnandVyas]

Hi @pmaturi83 

You can override the locale using the system option if you wish. Link to the details about this option: LOCALE System Option . It can be done platform level or user can also do it at their session level.

While SAS will automatically detect the change of native encoding and do the processing it will output in the log a note as below:

NOTE: Data file HEALTH.OXYGEN.DATA is in a format that is native to another 
      host, or the file encoding does not match the session encoding. Cross 
      Environment Data Access will be used, which might require additional 
      CPU resources and might reduce performance.

It's better to migrate SAS data and content to native Linux encoding. I believe you can use proc migrate to do that or if a new dataset created will be in native encoding.

There is a RedHat performance brief available to Optimizing SAS on Red Hat Enterprise Linux (RHEL) 6 & 7 . I think it's a good read to understand optimize the system based on your analytics requirements.

[JuanS_OCS]

Hello @pmaturi83 ,

I think most of your questions have been pretty well answered by @SASKiwi  and @AnandVyas .

My 2 cents to the story are:

- "locale" C in AIX (I guess you mean LC_ALL, but you also have LANG and other LC_* environment variables), is a tricky one, as basically overrides defaults in terms of locale, but also modifies the sorting https://unix.stackexchange.com/questions/87745/what-does-lc-all-c-do 

Nonetheless, in RedHat you should have the same environment variables, and I highly recommend to set them up in the same manner (unless there is a very good reason for it, architecturally. In that case, your architect should have assessed the impact of the change already. Check with your architects).

- Indeed, you will probably have CEDA messages as @AnandVyas mentioned. This has got 2 caveats: a) all your SAS processes will run slower, as SAS has to traconscode on-the-fly. b) your logs will reflect this fact as @AnandVyas mentioned, and not all companies will accept to have this information in the logs, as good practice.

Not only that, if you have SAS catalogs, they won't work at all, you need to migrate them.

I understand you have big chunks of data to process, and to migrate the data can be tedious, but I recommend to have it done.

This is an area that should have been assessed by your architects as well. If this is done, they will have a plan of actions. From my perspective, and from a very high level, a very common approach is to identify what is operational (used every day/month) and what is historical data (almost not used at all). This will help you with prioritization of data that needs to be migrated first, hopefully only 5 - 15% of the total data, which is a massive difference. The rest of the data can be migrated once you are in production phase, in much smaller chunks.

I hope it helps.

Best regards,

Juan