The MIGRATE Procedure |
What Are the Specific Considerations for Each Member Type? |
Here are the considerations for each member type. Remember that a SAS data set can be a data file or a data view. See also several important restrictions at Syntax: MIGRATE Procedure.
PROC MIGRATE retains compression, created and modified datetimes, deleted observations, encryption, indexes, integrity constraints, and passwords. The audit trail and generations are also migrated. Indexes and integrity constraints are rebuilt on the member in the target library. Migrated data files take on the data representation and encoding attributes of the target library. See Migrating a Data File with Audit Trails, Generations, Indexes, or Integrity Constraints.
As with data files, migrated data views take on the data representation and encoding attributes of the target library. When you migrate a library that contains DATA step views to a different operating environment, and the views were created before SAS 9.2, setting the proper encoding might be necessary. In releases before SAS 9.2, DATA step views did not save encoding information. Therefore, if the view has a different encoding than the target session, you must specify the INENCODING= option for the source library's LIBNAME statement. Here is an example:
libname srclib 'c:\mysource' inencoding="OPEN_ED-1047"; libname lib1 'c:\mytarget'; proc migrate in=srclib out=lib1; run;A note is printed to the log that recommends using the validation tools to recompile the DATA step view and determine whether the migration was successful. See Migrating a Library with Validation Tools.
In addition, embedded librefs associated with a view are not updated during migration. The following example illustrates the issue. In this example, LIB1.MYVIEW contains a view of the data file LIB1.MYDATA:
data LIB1.MYDATA;x=1; run; proc sql; create view LIB1.MYVIEW as select * from LIB1.MYDATA; quit;After you migrate LIB1 to LIB2, you have LIB2.MYVIEW and LIB2.MYDATA. However, because LIB2.MYVIEW was originally created with an embedded libref of LIB1, it still references the data file LIB1.MYDATA, not LIB2.MYDATA. The following example fails with an error message that LIB1 cannot be found:
proc print data=LIB2.MYVIEW; run;
PROC MIGRATE supports three types of views: DATA step views, SQL views, and SAS/ACCESS views:
Beginning with SAS 8, when you create a DATA step view, you can specify the SOURCE= option to store the DATA step code along with the view. PROC MIGRATE supports DATA step views with stored code. The stored code is recompiled the first time the DATA step view is accessed by SAS in the target environment. PROC MIGRATE does not support DATA step views that were created before SAS 8 or DATA step views without stored code. For DATA step views without stored code, use the DESCRIBE statement in the source session to recover the DATA step code. Then submit the DATA step code in the target session and recompile it.
PROC MIGRATE supports PROC SQL views with no known issues.
PROC MIGRATE supports SAS/ACCESS views that were written with the Oracle, Sybase, or DB2 engine. PROC MIGRATE automatically uses the CV2VIEW procedure, which converts SAS/ACCESS views into SQL views. Migrating SAS/ACCESS views to a different operating environment is not supported. For more information about the conversion, see the overview of the CV2VIEW procedure in SAS/ACCESS for Relational Databases: Reference.
To migrate catalogs, PROC MIGRATE calls PROC CPORT and PROC CIMPORT. You might notice that CPORT and CIMPORT notes are written to the SAS log during migration. PROC CPORT and CIMPORT restrictions apply. For example, catalogs in sequential libraries are not migrated.
Restriction: | PROC MIGRATE is not supported for SAS 6 AIX catalogs. Use PROC CPORT and PROC CIMPORT instead. See Additional Steps for Unsupported Catalogs. |
Requirement: | If CEDA processing is invoked, and if the source library contains catalogs, then you must specify the SLIBREF= option. If the catalogs were created in SAS 6 or SAS 8, SLIBREF= must be assigned through a SAS 8 server. See Using the SLIBREF= Option. |
PROC MIGRATE supports MDDBs with no known issues.
PROC MIGRATE does not support program files. If a program file exists in the library, a message is written to the SAS log.
PROC MIGRATE supports item stores unless you migrate from a 32-bit to a 64-bit environment. Migrations from 32-bit to 64-bit environments use RLS (Remote Library Services), which does not support item stores. In that case, an error message is not written to the SAS log, but item stores might not work correctly in the target library.
Migrating a Data File with Audit Trails, Generations, Indexes, or Integrity Constraints |
In all cases, the data file migrates first, and then the audit trails, generations, index, or integrity constraints are applied. Errors are handled in the following ways:
If an error occurs while an index is created for a migrated data file, the data file migrates without the index and a warning is written to the SAS log. If an index fails to migrate, resolve the error and recreate the index in the target library.
If an error occurs while integrity constraints are applied to a migrated data file, or while an audit trail or generations are migrated, the data file is removed from the target library. A note is written to the SAS log. If the MOVE option is specified, it does not delete the data file from the source library.
For a data file with referential integrity constraints, the MOVE option does not delete any members in the source library, even when the migration is successful. You must remove referential integrity constraints before the member can be deleted. An error message is written to the SAS log.
Migrating a SAS Data Set with NODUPKEY Sort Indicator |
When you migrate a SAS data set that was sorted with the NODUPKEY option, you can either use the default behavior or specify the KEEPNODUPKEY option.
Under the default behavior (without the KEEPNODUPKEY option), the SAS data set retains its sort indicator in the target library. However, the NODUPKEY attribute is removed, and a warning message is written to the SAS log. This is the default behavior because SAS data sets that were sorted with the NODUPKEY option in previous releases might retain observations with duplicate keys. You can re-sort the migrated SAS data set by the key variables in PROC SORT so that observations with duplicate keys are eliminated and the correct attributes are recorded.
If you specify the KEEPNODUPKEY option, you must examine your migrated data to determine whether observations with duplicate keys exist. If so, you must re-sort the SAS data set to have the data and NODUPKEY sort attribute match.
Migrating a SAS 6 Library |
For SAS 6 source libraries, the following operating environments are supported. Find your source operating environment in the first column and read across the row for information about the supported target operating environments.
If your libraries are not supported, see Alternatives to PROC MIGRATE. If only your catalogs are not supported, see Additional Steps for Unsupported Catalogs. For important information about the SLIBREF= option, see Using the SLIBREF= Option. See Examples.
SAS files that were created before SAS 6.12 (SAS 6.09E for z/OS) must be converted to SAS 6.12 before they can be migrated to the current release of SAS. See also Alternatives to PROC MIGRATE.
Migrating SAS Data Sets that Contain Non-English Characters |
For SAS data sets that use the ASCII-OEM character set, PROC MIGRATE does not translate non-English characters. To migrate a SAS data set with ASCII-OEM characters to the current release of SAS, use the CPORT and the CIMPORT procedures with the TRANTAB option. Specify the appropriate TRANTAB values for the source and target data sets.
The following example specifies p850wlt1 and wlt1wlt1 for the old and new translation tables, respectively. You can check the output from the PRINT procedure to determine whether the non-English characters translate correctly.
options trantab =(p850wlt1,wlt1wlt1) ; libname source v6 "source-library-pathname" ; libname target base "target-library-pathname" ; title1 "SAS data set containing non-English characters"; title2 "source library"; proc print data=source.filename; run; proc cport lib=source file="souce library-pathname\filename" ; run ; proc cimport lib=target infile="target library-pathname\filename" ; run ; title2 "compare this output with output from the source library"; proc print data=target.filename ; run ;
Migrating Files with Short Extensions on PC Operating Environments |
In SAS 7 and 8, the SHORTFILEEXT option creates a file with a shortened, three-character extension on PC operating environments only. This feature is necessary for operating systems that use a FAT (file allocation table) file system. The FAT file system is also referred to as 8.3 because a filename can include up to eight characters and a file extension can include up to three characters. These files are created on PC environments. They are not usable by SAS on other environments.
Note: SAS 6 files all have three-character extensions but are not affected by this issue. You can distinguish SAS 6 files because their extensions do not contain the number 7.
Below is a table of the short and standard extensions for SAS 7 and 8 files. To determine whether a library contains files with short extensions, look at the filenames in the SAS Explorer or use the file management tools of your operating environment.
Memtype | Short Extension | Standard Extension |
---|---|---|
ACCESS | sa7 | sas7bacs |
AUDIT | st7 | sas7baud |
CATALOG | sc7 | sas7bcat |
DATA | sd7 | sas7bdat |
DMDB | s7m | sas7bdmd |
FDB | sf7 | sas7bfdb |
INDEX | si7 | sas7bndx |
ITEMSTOR | sr7 | sas7bitm |
MDDB | sm7 | sas7bmdb |
PROGRAM | ss7 | sas7bpgm |
PUTILITY | sp7 | sas7bput |
UTILITY | su7 | sas7butl |
VIEW | sv7 | sas7bvew |
supports the SHORTFILEEXT option, although it is not documented. If you use this option, you have read and write access to your existing short-extension files.
do not support any access to short-extension files. You can use PROC COPY in SAS 8 to copy the short file extensions to standard file extensions before migrating your files to SAS 9.
As an alternative to PROC COPY, if you are comfortable using operating system commands or file management tools, you can manually change the file's extension to the standard extension. The content of a short-extension file is identical to the content of a standard-extension file. The use of operating system commands is not supported by SAS.
support read-only access to existing short-extension files. You can migrate your library to the current release of SAS by using PROC MIGRATE. You must specify the SHORTFILEEXT option on the LIBNAME statement for the source library. The files are written to the target library with standard extensions; the files support full access.
For example, a library named MYLIB contains two files with short extensions: a SAS data set named mydata.sd7 and a catalog named mycat.sc7. Use the following code to migrate the library to SAS 9:
libname mylib v8 'source-library-pathname' shortfileext; libname newlib v9 'target-library-pathname'; proc migrate in=mylib out=newlib; run;
After migration, the target library NEWLIB contains two files with standard extensions: a SAS data set named mydata.sas7bdat and a catalog named mycat.sas7bcat.
If your library also contains standard-extension files, then perform an additional migration without the SHORTFILEEXT option on the LIBNAME statement to migrate those files. Make sure that no short-extension files have the same name as a standard-extension file. In the target library, all files have a standard extension. If a short-extension file and a standard-extension file have the same name and same member type in the target library, the second one fails to migrate.
Copyright © 2010 by SAS Institute Inc., Cary, NC, USA. All rights reserved.