10-10-2017 09:45 AM
I need some help with Migration.
We are migrating from a SAS standalone server which is on Solaris 10 to Linux ( Red hat Which is going to be a grid Environment).
So i am currently in the process of Migrating the Programs and applications they have to the Linux Grid Env.
What will be the best methods to Migrate the Programs and Applications?
What changes will i need to make to the Programs also as they are planning to run them from the Command line, so that they can excute on the Grid?
Also if there are shell scripts what changes will i need to make to them so they can execute on the Linux Grid?
10-10-2017 11:10 AM
Forgive me, you didn't mention this, but maybe just as a learning to the greater community.
How will you be handling the conversion of you SAS datasets from Solaris to Linux ? Depending how much data you have, this can be a big task as well.
10-10-2017 11:20 AM
10-11-2017 12:26 AM
So, for the SAS dataset migration, there are couple of methods which should work, so I don't want to delve into the merits of each. But I can share a couple experiences from our migration a while back.
Our migration was also from SAS 9.2 on Solaris 10 SPARC to SAS 9.4 on SUSE.
To migrate the datasets (~150TB), we ended up writing a very simple macro that simply assigns a local libname on Solaris and a remote libname on Linux using SAS/Connect. When the users were ready to migrate their data, they simply invoked the macro from Enterprise Guide. This had the following pros and cons:
- The moment SAS 9.4 creates the dataset on Linux, is already ""converted" to Linux x64 encoding. No export->import, one action and it's done.
- You don't need to double up on you disk space on Linux (for packages) since the data goes straight into it end state
- We had ~150TB of SAS datasests and didn't have a single issue in terms of compatibility, data loss, data corruption, etc.
- It is user driven, The users can decide exactly when they want to migrate as not to disrupt current business processes.
- It takes long. SAS/Connect is not the fastest engine, but given the benefits we derived from this approach, it didn't matter. If you allow yourself enough time to migrate the data, then you're fine. It's the lastminute.com users that were a problem.
- Switch on dataset compression on Linux from day 1. This way all your migrated datasets are compressed from the beginning.
- Do not allow users to FTP the data across. They will try and take shortcuts to move the data, but then you land up with Solaris-encoded data on Linux. Although SAS does handle this by means of CEDA, you increase you CPU usage and you cannot update those datasets until converted.
All the best !