Moving from HP-UX to Linux

[MariaD]

Hi folks, 

We are moving our SAS server from HP-UX to Linux. Unfortunately, we don't have space to work with CPORT/CIMPORT.

So, we understand we need to recreate all index on Linux in order to work with the SAS datasets.

We prepare a test and copy, through FTP, some files to the Linux server. In Linux we created a LIBNAME pointed to this copied files. The LIBNAME under SAS EG doesn't shows the tables with index but we could execute PROC CONTENTS on it without any problem. 

We tried to execute PROC DATASETS to recreate the index for this tables, but an error appears because the procedure can't locate the table.

So, we execute DATA / SET recreating the table on WORK. After that, we execute again DATA / SET copying from WORK to the LIBNAME. The process executes fine but we still can't see the table on the LIBNAME. 

We also tried to execute PROC COPY to WORK libname but the same error as we encounter on PROC DATASETS appears. 

Any suggestion?

Regards, 

[MargaretC]

In order to recreate the index, you must convert the SAS data file from HP-UX format to Linux format. This is what the CPORT/IMPORT does for you. You can also copy the original HP-UX file to a new Linux file using a DATA step. After you have the SAS file in native (Linux) format, you can recreate the index. And apply custom formats to it.
Margaret

[SASKiwi]

@MariaD  - Am I correct in assuming that datasets without indexes show and read OK with a linux LIBNAME if copied via FTP from your Unix server? And that only datasets with indexes cause problems?

Please remember if you FTP a SAS dataset with an embedded index definition then you will likely have problems with this on linux as no such index exists. Try removing the index from the dataset first before copying it with FTP and see if that works OK. Then recreate the index on linux and see if that works OK.

[MargaretC]

This will not work because you can only read SAS data files created in HP-UX on a Linux system. It is because one is big endian and the other is little endian.
If you look at the SAS log you will see you are accessing the SAS data file on Linux via the Cross-Environment Data Access (CEDA) interface. Details of CEDA can be found here: https://go.documentation.sas.com/?docsetId=movefile&docsetTarget=p0mvwvg25ceml5n1c2digfpk6vkh.htm&do...
Margaret

[MariaD]

Hi @MargaretC , but if we execute a data step, we can able to open the dataset on WORK libname (under Linux server) without any problem. If we execute a data step again, reading from WORK libname to the original libname, according to the log information, process finish ok, but we can't see this datasets on the original libname. We tried to use OUTREP option but without any change on the behaviour. 

Regards, 

[MargaretC]

What happens if you move the WORK SAS data file to a different SAS library? I am not sure you can have mixed SAS data files (little endian and big endian) in the same SAS library.

[MariaD]

Hi @MargaretC ,

I'll try tomorrow (now I don't have access to the environment) and let you know. 

Thanks!

[MariaD]

Hi @MargaretC ,

It's really strange the situation. I recreated one of the tables with problem (change the name of the table too). And, as part of the test, I recreated one of the table with no problem too. 

If I execute a PROC CONTENTS for both tables, the information are the same:

 

But the second one (TEST table) I no able to see on the LIBNAME.

Any idea?

[MargaretC]

Please open a SAS Technical Support track.

[MariaD]

Thanks @SASKiwi. As could see, the datasets with index or orders have the same behaviour. The files were copied using FTP, the index was copied too. We tried to delete the index file (through OS) but the same occurs. 

We know that we need to recreate the index on Linux. We also tried to recreate the datasets (using data step). The tables was created and we can open it from WORK (on Linux server) fine. After that, using again data step, we saved it to the original LIBNAME. According log, table was created but we still no seeing. 

Regards,

[Patrick]

@MariaD You've got already all the help you need so not adding to it but just asking questions:

"Unfortunately, we don't have space to work with CPORT/CIMPORT."

If you've got the space on the target server to re-create the tables then can't you just go for multiple batches where you just cport/cimport some of the tables per batch.

Also: Should you have SAS/Connect on both servers then using Proc Migrate would be another option.

[SASKiwi]

@Patrick  - Agreed. The options suggested either CPORT/CIMPORT or SAS/CONNECT with PROC MIGRATE or PROC UPLOAD have already been made in previous posts by @MariaD. SAS/CONNECT is the better option for the OP as there is no need to create intermediate CPORT files and that would save space also.

As I understand it PROC MIGRATE doesn't handle indexes but I'm pretty sure PROC UPLOAD does. 

[maggiem_sas]

PROC MIGRATE does handle indexes. The details for data sets says "Indexes and integrity constraints are rebuilt on the member in the target library." Here's some example code that uses SAS/CONNECT. Substitute your host name, port, user ID, password, and paths.

options comamid=tcp;
%let myserver=host.name.com;
signon myserver.__1234 user=userid password='mypw'; 

libname source 'source-library-pathname' server=myserver.__1234;
libname target 'target-library-pathname';

proc migrate in=source out=target <options>;
run;
signoff myserver.__1234;

[MariaD · Accepted solution]

Thanks all, we finally discover the problem. Inside the directory, there was a file (not a SAS data sets) with an strange character (results of file with accents/latin characters). After we renamed the file, the problem was resolved.

Regards,  

[Kurt_Bremser]

It is not a good idea to have anything not created by SAS in a directory used as a SAS library.