07-16-2012 11:32 AM
We are migrating our SAS Environment from Solaris x86 to Linux x86 environment & need to migrate all existing SAS datasets to new environment.
I have used proc cport & cimport to do this. Is there a better way to do this? Also is there a way to validate if SAS dataset if optimized to current environment?
07-16-2012 12:55 PM
Do you even need to do anything? Unless your Linux is on an IBM mainframe then SAS should be able to read them.
It should put out a message if it needs to resort to the CEDA engine to convert on the fly.
You should be able to determine the representation for a dataset useing the DATAREP field in the dictionary table TABLES.
07-16-2012 02:06 PM
Yes, SAS datasets will work with CEDA. As there are few limitations & using CEDA consumes additional cpu overhead, we are planning to migrate these datasets into respective native format.
07-16-2012 03:39 PM
Not sure what the question is then.
Are you not able to distinguish between the migrated and non-migrated versions using the fields in either PROC CONTENTS output or the DICTIONARY tables?
07-16-2012 04:08 PM
I think that Nithin misinterpreted your first comment. As I read it, you were saying
Do a simple copy of a SAS dataset to the new environment. Open it with SAS in the new space. If it uses CEDA, then he should convert the files with CPORT/CIMPORT. If not, all he needs to do is copy the files using *nix utilities.
I agree with Nithin that using CEDA for long-term production work might be problematic.
07-16-2012 04:15 PM
Another way of moving SAS data between different operating systems but maintaining "native" and optimal format is to use SAS/CONNECT and the UPLOAD/DOWNLOAD procedures. If this way is used then there is no need to CPORT/CIMPORT, even with SAS catalogs as SAS handles any translations internally. Of course you do need SAS/CONNECT licensed.
07-17-2012 09:26 AM
Thanks for the suggestions. To clarify couple of items :
1) We are migrating SAS datasets between 2 environments(Solaris x64 to Linux x64), we need them to be in native format. Hence, CEDA is not used while accessing them.
2) CPORT/CIMPORT works well for this situation. However, we are planning to provide scripts to SAS users to convert their individual SAS datasets. I want this script to validate if the dataset is in native format & then convert using CPORT/CIMPORT if needed.
07-17-2012 09:48 PM
A approach is making a Linux x64 version dataset at local Solaris x64 computer, then transport it to your desired destination .
OUTREP= Data Set Option
Specifies the data representation for the output SAS data set.
OUTREP= Value Alias* Environment
ALPHA_TRU64 ALPHA_OSF Tru64 UNIX
ALPHA_VMS_32 ALPHA_VMS OpenVMS on Alpha
ALPHA_VMS_64 OpenVMS on Alpha
HP_IA64 HP_ITANIUM HP-UX on Itanium 64-bit platform
HP_UX_32 HP_UX HP-UX on 32-bit platform
HP_UX_64 HP-UX on 64-bit platform
INTEL_ABI ABI UNIX on Intel 32-bit platform
LINUX_32 LINUX Linux for Intel Architecture on 32-bit
LINUX_IA64 Linux for Itanium-based system on
LINUX_X86_64 LINUX on x64 64-bit platform
MIPS_ABI ABI UNIX on 32-bit platform
MVS_32 MVS z/OS on 32-bit platform
OS2 OS/2 on Intel 32-bit platform
RS_6000_AIX_32 RS_6000_AIX AIX UNIX on 32-bit RS/6000
RS_6000_AIX_64 AIX UNIX on 64-bit RS/6000
SOLARIS_32 SOLARIS Solaris on SPARC 32-bit platform
SOLARIS_64 Solaris on SPARC 64-bit platform
SOLARIS_X86_64 Solaris on x64 64-bit platform
VAX_VMS OpenVMS VAX
VMS_IA64 OpenVMS for HP Integrity servers
WINDOWS_32 WINDOWS Microsoft Windows on 32-bit platform
WINDOWS_64 Microsoft Windows 64-bit Edition (for
both Itanium-based systems and x64)
07-24-2012 10:16 PM
Sure. Check it at dictionary table.
Notice "Data Representation Name" column contains the information you need.
data class; set sashelp.class;run; data class1(OUTREP=linux); set sashelp.class;run; proc sql; create table x as select * from dictionary.tables where libname='WORK'; quit;