BookmarkSubscribeRSS Feed
Mahek__Parikh
Fluorite | Level 6

Hi

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?


7 REPLIES 7
nhvdwalt
Barite | Level 11

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.

Mahek__Parikh
Fluorite | Level 6

Agreed to that,

Was thinking of Using Proc Cport and Proc CImport?

Mahek__Parikh
Fluorite | Level 6

Also if not that what will be a better Solution to use to Convert the Datasets from Solaris to Linux

maheshtalla
Quartz | Level 8
Also should consider the version of sas during migration. If SAS on Solaris version is lesser to the Linux then you might face comparability issues.
Mahek__Parikh
Fluorite | Level 6

Yes the Solaris SAS version is 9.2 and the new version is going to SAS 9.4 on Linux Grid

maheshtalla
Quartz | Level 8

Hi Mahek,

Then you have to go with manual migration and best way is to use with proc cport and cimport as you mentioned. 

nhvdwalt
Barite | Level 11

 

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:

 

PROS:

- 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.

 

CONS:

- 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.

 

REMEMEBER:

- 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 !

 

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 

Get Started with SAS Information Catalog in SAS Viya

SAS technical trainer Erin Winters shows you how to explore assets, create new data discovery agents, schedule data discovery agents, and much more.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 7 replies
  • 2573 views
  • 6 likes
  • 3 in conversation