Preventing and Fixing Problems

Troubleshooting: Transferring and Restoring Transport files

To avoid potential problems when transferring a transport file to the target computer, ensure that these conditions have been met:

If transferring across the network, verify that the transport file is transferred in binary format. For details, see Transferring the Transport File in Binary Format.
Verify that the transport file has not been corrupted. For details, see Verifying That the Transport File Has Not Been Corrupted.
Verify that the communications software does not change file attributes. For details, see Verifying That the Communications Software Has Not Changed File Attributes.
Consider invoking the communications software at the target computer and getting the transport file from the source computer. For details, see Invoking the Communications Software at the Target Computer.
Do not mix methods to create the transport file at the source computer and then restore the transport file at the target computer. For details, see Using Compatible Transport Strategies at the Source and Target Computers.
Before you transfer a transport file to the target computer, validate the integrity of the transport file by restoring it to the source computer that created it. For details, see Validating the Integrity of the Transport File.
If transferring by means of tape, use an unlabeled tape. For details, see Using an Unlabeled Tape.
If transferring a large transport file by means of tape, break up the library into multiple libraries and transport each one to tape. For details, see Dividing a Large Transport File into Smaller Files for Tape.

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 computer, 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 computer. The insertion of carriage returns and line feeds corrupts the transport file and makes it impossible to restore the file at the target computer. For details about how to identify 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 or an integer that is a multiple of 80 (for example, 160, 240,320).
Block size (BLKSIZE)	8000 blocks
Record format (RECFM)	Fixed block

See your communications software documentation for information about controlling these attributes.

At the target computer, if you have a transport file that has not been corrupted (that is, carriage returns or line feeds have not been inserted), but its record block size is incorrect and you are unable to obtain a correctly blocked transport file, you might 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 Computer

To transfer the transport file to the target computer, you might be more successful if you invoke the communications software at the target computer instead of invoking it at the source computer. You probably cannot put a file in a location on the target computer because you do not have write permission. If transferring a transport file from UNIX to z/OS, you are advised to invoke the communications software at the z/OS computer. Because you probably have read permission at the UNIX computer, you can get the transport file and write it to your z/OS computer.

Using Compatible Transport Strategies at the Source and Target Computers

Do not mix strategies to create the transport file at the source computer and then restore the transport file at the target computer. The strategies 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 computer. You can also create a transport file using PROC CPORT at the source computer and import the transport file using PROC CIMPORT at the target computer. Do not create a transport file using the XPORT engine and PROC COPY at the source computer and then try to use PROC CIMPORT to restore the transport file at the target computer.

To identify the strategy that was used to create a transport file, use a text editor or an operating environment read or view command to read the file in SAS 9 on any computer that represents character data as ASCII.

Note: For information about viewing transport files on operating environments that represent character data as EBCDIC, see Reading Transport Files in z/OS Operating Environments. [cautionend]

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 specify the NOCOMPRESS option in PROC CPORT, compression is suppressed, which prevents the display of the preceding text in a transport file. [cautionend]

Validating the Integrity of the Transport File

To validate the integrity of the transport file before it is transferred to the target computer, use the appropriate strategy and try to read it back into native format at the source computer.

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 computers, reading a file from a standard labeled tape might be somewhat complicated at the target computer.

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

Top of Page