Cross-Architecture Restrictions and Limitations

In cross-architecture catalog access, clients have read-only access to the SAS catalogs, but they cannot create, replace, or update SAS catalogs.

The client application specifies a catalog by using the libref and catalog names. This causes the entire catalog to be stored in a transport file on the server and imported by the client. The catalog is stored in the client's WORK library under an automatically generated name, such as the following:

WORK._SASXHST_00000000000001023144088.CATALOG

A maximum of three imported catalogs at a time might be stored in the client's WORK library. A subsequent read of the original catalog by using the libref and catalog name might read from the imported copy of the catalog in the WORK library, depending on whether the catalog on the server has been modified since the last read by the cross-architecture client. If more than three cross-architecture catalogs are imported, the least recently used catalog is deleted to make room for the most recently used catalog.

The CONTENTS and the CATALOG procedures can be used to examine the imported catalogs in the WORK library. The DATASETS procedure can be used to delete these catalogs.

By default, the SAS/SHARE server uses the library WORK to cache the transport files on the server in the SAS library SASCATCA. However, you can use the SERVER procedure ALLOCATE LIBRARY command to assign the cache to a different SAS data library. The files in this library are stored in the transport format of SAS catalogs. For example:

proc server id=shr1;
allocate library mycache '/catalog/cache' libtype=catcache;
run;

You might want to assign the cache to a different SAS library in order to accomplish the following:

Although the server caches a maximum of three transport files, an administrator can change the default. The ALLOCATE LIBRARY command, issued in the SERVER procedure, has a CATCACHELIMIT option in which you can specify the number of catalogs that are stored in the library SASCATCA. For details, see ALLOCATE LIBRARY Statement.

You can concatenate catalogs to minimize changes to an application and to increase efficiency when accessing cross-architecture catalogs. Set up a catalog concatenation in the client session that uses the same librefs and catalog names that the application already uses.

Two new catalogs are used in a concatenation:

Using catalog concatenation in the server session is not recommended, because a client that reads an entry in the concatenation will retrieve the entire concatenation as a single catalog, which could be large. Large catalogs can take a long time to read or retrieve entries from.

Catalog concatenation on the server can be an advantage if you have many small catalogs that will be accessed simultaneously. Having all of the catalogs concatenated under one name enables the client to keep that catalog in the library WORK. Having a single concatenated catalog reduces the possibility of thrashing, which can result if the client needs more than three catalogs in the library WORK. Thrashing occurs when catalogs are deleted and then retrieved.

Direct access to PROC SQL views is provided, but SAS view files (type VIEW) cannot be directly accessed across architectures. A DATA step or SAS/ACCESS view can be read cross-architecture as long as it is interpreted in the server session. In this case, you should not specify the RMTVIEW=NO option in the client LIBNAME statement because that option requests interpretation in the client SAS session and requires the SAS view file itself to be transferred to the client session. For more information, see SAS Data View Programming Considerations.

Access descriptor files (type ACCESS) cannot be accessed across architectures. Access descriptors are special files that are produced and used by SAS/ACCESS products to describe data in other vendors' databases, such as DB/2 or Oracle. Although cross-architecture interpretation of a SAS/ACCESS view is supported, direct access to the descriptor file is not. Therefore, you cannot use PROC ACCESS to create a SAS access descriptor file on a computer that has a different architecture.

SAS files of type PROGRAM cannot be accessed across architectures. These files contain compiled DATA step code. You cannot execute such a DATA step in your local SAS session by using the PGM= option in the DATA step, nor can you write a DATA step PROGRAM entry to a cross-architecture server. A DATA step PROGRAM entry can be executed in a cross-architecture server session if it is referenced by a DATA step view that is interpreted there.

In order for SAS data sets to be accessed across architectures, they should not include two-byte numeric variables. This length is allowed on IBM mainframe machines, but other operating environments that SAS runs on have a minimum numeric variable length of three. As a result, a data set that contains a two-byte numeric cannot be accessed across architectures from other types of operating environments.

With clever programming in the DATA step, it is possible to store numeric values in character variables and character values in numeric variables. However, you should not create data sets this way if you want to access them across architectures. SAS/SHARE performs appropriate character translation of character variables and numeric translation of numeric variables when crossing architectures. However, storing numeric values in character variables and character values in numeric variables will not be preserved. SAS/SHARE has no means to detect such usage.