|Moving and Accessing SAS Files across Operating Environments|
To avoid potential problems when transferring a transport file to the target host, ensure that these conditions have been met.
Remaining sections explain these topics in detail.
|Transferring the Transport File in Binary Format|
When transferring a transport file using the communications software, verify that the file is transferred in binary (or image) format. The content of the file must be transferred in sequential bytes without modification.
If you use FTP to move a transport file to the target host, you should first specify BINARY 80 before transferring the file.
If you use PATHWORKS, use the SEQUENTIAL_FIXED attribute when you set the file_server service using PCSA_MANAGER. The default attribute is STREAM, which is not appropriate for moving transport files.
|Verifying That the Transport File Has Not Been Corrupted|
Verify that your communications software does not insert a carriage return to mark an end of record in the transport file during transfer to the target host. The insertion of carriage returns and line feeds corrupts the transport file, making it impossible to restore at the target host. For details about how to determine this condition, see the recovery actions for File libref.ALL is damaged. I/O processing did not complete.
|Verifying That the Communications Software Has Not Changed File Attributes|
Verify that your communications software does not change file attributes. Here are the required attributes with values:
|Logical record length (LRECL)||80|
|Block size (BLKSIZE)||8000 blocks|
|Record format (RECFM)||Fixed block|
See your communications software documentation for information about controlling these attributes.
At the target host, if you have a transport file that has not been corrupted (carriage returns or line feeds have not been inserted), but whose record block size is incorrect and you are unable to obtain a correctly blocked transport file, you may run a reblocking program to fix the blocks to the correct size. For details, see Reblocking a Transport File.
|Invoking the Communications Software at the Target Host|
To transfer the transport file to the target host, you may be more successful invoking the communications software at the target host than at the source host. You probably cannot put a file in a location on the target host because you do not have write permission. For example, if transferring a transport file from UNIX to CMS, you are advised to invoke the communications software at the CMS host. Because you probably have read permission at the UNIX host, you can get the transport file and write it to your CMS host.
|Using Compatible Transport Methods at the Source and Target Hosts|
Do not mix methods to create the transport file at the source host and then restore the transport file at the target host. The methods that you use must be identical or be a companion pair. For example, create and restore a transport file using the XPORT engine and PROC COPY at both the source and target hosts. Likewise, create a transport file using PROC CPORT at the source host and import the transport file using PROC CIMPORT at the target host. Do not, for example, create a transport file using the XPORT engine and PROC COPY at the source host and then try to use PROC CIMPORT to restore the transport file at the target host.
To determine the method that was used to create a transport file, use a text editor or an operating system read or view command to read the file on any Version 8 host that represents character data as ASCII.
Note: For information about viewing transport files on hosts that represent character
data as EBCDIC, see Representing EBCDIC as ASCII or Hexadecimal Data.
The XPORT engine creates a file whose first line contains this ASCII text:
HEADER RECORD*******LIBRARY HEADER RECORD!!!!!!!00
PROC CPORT creates a file whose first line contains this text:
**COMPRESSED** **COMPRESSED** **COMPRESSED**
Note: If you set the NOCOMPRESS option to PROC
CPORT, compression is suppressed, which prevents the display of the preceding
text in a transport file.
|Validating the Integrity of the Transport File|
To validate the integrity of the transport file before it is transferred to the target host, using the appropriate method, try to read it back into native format at the source host.
Here is a PROC COPY example:
/* This PROC COPY creates the transport file TRAN. */ libname tran xport 'transport-file'; libname grades 'SAS-data-library'; proc copy in=grades out=tran memtype=data; run; /* This PROC COPY reads back transport file TRAN. */ libname grades 'SAS-data-library'; libname tran xport 'transport-file'; proc copy in=tran out=test; run;
Here is a PROC CPORT and PROC CIMPORT example:
/* This PROC CPORT creates the transport file. */ libname grades 'SAS-data-library'; filename tran 'transport-file'; proc cport library=grades file=tran; run; /* This PROC CIMPORT reads back the transport file. */ filename tran 'transport-file'; libname grades 'SAS-data-library'; proc cimport library=grades infile=tran; run;For both examples, check the log for error messages.
|Using an Unlabeled Tape|
When transferring a transport file by means of tape, use an unlabeled tape. Because tape labels are processed differently in different operating environments, reading a file from a standard label tape may be somewhat complicated at the target host.
|Dividing a Large Transport File Into Smaller Files for Tape|
When transferring a transport file by means of tape, if the transport file exceeds the capacity of one tape, rather than using multi-volume tapes, you should divide the original library into two or more libraries and create a separate, unlabeled tape for each one. The original library can be restored at the target host.
Top of Page
Copyright 1999 by SAS Institute Inc., Cary, NC, USA. All rights reserved.