Library Implementation Types for Base and Sequential Engines

Overview of Library Implementation Types

For a given engine, a SAS library can be implemented in a variety of forms that have different usability and performance characteristics. These implementation types and the engines with which they can be used are listed in the following table. A complete description of each library can be found in the sections that follow.
Types of Libraries and Supported Engines
Implementation Type
Engines Supported
Direct Access Bound Library
V9, V8, V7, V6
Sequential Access Bound Library
V9TAPE, V8TAPE, V7TAPE, V6TAPE
UFS Library
V9, V8, V7, V9TAPE, V8TAPE, V7TAPE
Hiperspace Library
V9, V8, V7, V6
Pipe Library
V9TAPE, V8TAPE, V7TAPE, V6TAPE

Direct Access Bound Libraries

Overview of Direct Access Bound Libraries

A direct access bound library is a single z/OS data set, accessed on disk or hiperspace. It logically contains one or more SAS files in a manner similar to that of a z/OS partitioned data set (PDS). However, unlike a PDS, the members of a direct access bound library can be read, written, or managed only by SAS. Direct access bound libraries support the requirements of the Base SAS engines, particularly the need to randomly access SAS files and to have more than one SAS file open simultaneously. Direct access bound libraries can extend to as many as 59 physical direct access storage device (DASD) volumes. As with a PDSE, SAS can reuse space in these libraries when a member is deleted or shortened. SAS performs most of its I/O asynchronously to direct access bound libraries. This process enables SAS servers that are accessing these libraries to perform other work while I/O operations to these libraries are in progress. For more information, see Using Multivolume SAS Libraries.

Creating Direct Access Bound Libraries

There are many ways to create a direct access bound library, but all methods have two points in common: First, the library physical name must correspond to a new or empty z/OS data set on DASD. Second, the library data set must have the DCB attribute DSORG=PS, and RECFM, if specified, must be FS. The second requirement is met if a Base SAS engine is explicitly specified in the LIBNAME statement that is used to identify the library.
The first time a new direct access bound library is used, it is initialized with the control structures that are necessary to manage library space and maintain the directory of library members.
The following example uses the LIBNAME statement with the default library options: 
libname study '.study1.saslib' disp=(new,catlg);
data study.run1;
 ...
run;
These SAS statements use the V9 engine to create a library named prefix.STUDY1.SASLIB where prefix is the value of the SYSPREF system option. The amount of space allocated to the library is derived from the value of the FILEUNIT, FILESPPRI, and FILESPSEC system options. SAS automatically sets the appropriate DCB attributes. In an interactive session, it is possible to omit the DISP option; in this case, SAS assumes a status of NEW and prompts for the value of the normal disposition.
The following example creates an external assignment using JCL: 
//jobname JOB ...
//   EXEC SAS
//STUDY DD DSN-USER489.STUDY1.SASLIB,DISP=(NEW,CATLG),
//      UNIT=DISK,SPACE=(CYL,(200,50)),DCB=DSORG=PS
data study.run1;
  ...
run;
Assuming that the ENGINE system option uses the default of V9, these SAS statements create a library named USER489.STUDY1.SASLIB.
As in the previous example, SAS automatically sets the appropriate DCB attributes. Note that it is not necessary to specify the LIBNAME statement.
The following example explicitly specifies the V6 compatibility engine: 
//jobname JOB ...
//   EXEC SAS
//HIST DD DSN=USER489.HISTORY1.SASLIB,DISP=(NEW,CATLG),
//       UNIT=3390,SPACE=(CYL,(10,10)),
//       DCB=(DSORG=PS,BLKSIZE=27648)
libname hist V6;
data hist.analysis;
        ...
run;
Like the previous JCL example, this example uses external assignment. However, the V6 compatibility engine is explicitly specified in the LIBNAME statement. This library can now be processed by SAS Version 6. In addition, the DD statement in the JCL explicitly specifies the library block size.

General Usage Notes

  • Only one SAS session can open a direct access bound library for update at a given time. It is necessary to specify a disposition status of NEW, OLD, or MOD in order to update a SAS library. However, multiple SAS sessions can share a SAS library for read-only access using DISP=SHR. Except for a special case of relevance only during the installation of the SAS product, SAS does not allow updates of a library that is allocated DISP=SHR.
  • The mode in which SAS opens the library data set is governed by the disposition status with which the library data set is allocated and the RACF authorization the user has to the library data set. If the disposition is SHR, SAS will treat the library as read-only. Otherwise, SAS will assume that the user has read-write access. SAS then issues a RACROUTE call to verify that the SAS job step is authorized to open the library data set in the requested manner (read-only or read-write). If read-write access is requested but not authorized, then SAS will check to determine whether read-only access is authorized. If permitted, SAS will treat the library as read-only even though DISP=OLD is specified. After that series of checks, SAS then opens the library in the authorized manner: INPUT mode is used for read-only libraries. For read-write libraries, OUTPUT mode is used to open the data set on the last (or only) volume; UPDATE mode is used for volumes that are not the last one. Of course, if SAS is not authorized to access the library at all, it does not attempt to open the library. Note, however, that the RACF authorization check is not performed if the system option FILEAUTHDEFER has been specified.
  • The data set in which a direct access library resides is itself a simple physical sequential data set. Therefore, the library data set can be copied or backed up (subject to the following restrictions) to disk or to tape by using any z/OS utilities such as IEBGENER, ISPF 3.3, DF/HSM, or DFDSS that honors the requirements of RECFM=FS. The library data can be copied to a different disk device type (with a different track size) than the original, and SAS can then successfully process the copy. The library data set can also be copied via FTP if the FTP mode is set to binary and the copy of the data set has the same DSORG, RECFM, BLKSIZE, and LRECL attributes as the original. However, even though the library data set can be copied to tape (such as for the purposes of transport or archive), SAS cannot open the data set unless it resides on DASD.
  • The library data set for a direct access bound library must not be copied or backed up while SAS has the library open for update. Failure to respect this restriction can lead to loss of data. Utility programs that respect the DISP=OLD allocation, and that run in an address space separate from the SAS session, will comply with this restriction.
  • Multivolume direct access bound libraries that were last processed by SAS®9 (or SAS 8 at a current maintenance level) can be successfully copied by standard utilities, regardless of the engine format. However, multivolume direct access bound libraries that were last processed by earlier versions of SAS could have the DS1IND80 bit (last volume flag) turned on for each volume. Utilities that honor the DS1IND80 flag terminate the copy operation at the first volume for which the flag is on. Libraries for which the DS1IND80 flag is on for all volumes (or any volume except the last volume with data) cannot be copied in their entirety by such utilities. This problem exists for any library that was last processed by SAS 6. The problem might also exist for any library last processed by SAS 8 but only if the SAS session abended. For this reason, SAS recommends using the COPY procedure for libraries that are processed by those older versions of SAS.
  • When rewriting a SAS file in a direct access bound library, SAS does not delete the old copy of the file until the entire SAS file has been completely rewritten. The library grows large enough to contain both the old and new version of the file.
  • SAS reclaims free space in a direct access bound library for its own use. It does not release free space back to the operating system as part of normal processing. To make free space available for other z/OS data sets, use the COPY procedure to copy all of the members of the library to another smaller library, and then delete the original copy. Unformatted free space at the end of the library data set (that is, the difference between “Total Library Blocks” and “Highest Formatted Block” in the CONTENTS procedure output) can be released by specifying the RLSE subparameter of the SPACE parameter when accessing a library for update. The RELEASE procedure can release both formatted and unformatted free space at the end of a library (that is, space that follows “Highest Used Block” as indicated by the CONTENTS procedure or the DATASETS procedure), but it can be used only for libraries that reside on a single volume. Neither the RLSE subparameter nor PROC RELEASE can be used to release embedded free space in a direct access bound library, that is, free blocks below “Highest Used Block.”
  • The value for “Total Library Blocks” reported by PROC CONTENTS and PROC DATASETS reflects only space on volumes for which the library has formatted blocks. It does not include preallocated space on volumes to which the library data set has not yet been extended.
  • The COPY procedure can also be used to re-organize a direct access bound library so that all the blocks of each SAS file reside in contiguous library blocks. This re-organization could improve the efficiency of frequently processed libraries.
  • Because SAS uses EXCP to process direct access bound libraries, the direct access bound libraries cannot reside in extended format sequential data sets. However, direct access bound libraries can reside in DSNTYPE=LARGE data sets. In that case more than 64K tracks can be used on each volume.
  • For direct access bound libraries that reside in DSNTYPE=BASIC data sets, a maximum of 64K tracks can be used on any single volume. Because a single data set cannot reside on more than 59 volumes, the maximum size for a such a library is approximately 199 G bytes (assuming optimal half-track blocking on a 3390 device).
  • For direct access bound libraries that reside in DSNTYPE=LARGE data sets, a maximum of 224–1 (about 16 million) tracks can be used on any single volume. In addition, the total number of blocks for the entire library on all volumes cannot exceed 231–1 (about 2 billion). To avoid encountering the block limitation for multi–volume data sets that reside on EAV volumes, use half-track blocking (27648 on a 3390 device).
  • A direct access bound library that is externally allocated with DISP=MOD cannot be assigned if the library has been extended to more than one volume. This restriction also applies when re-assigning a library using an external allocation that was previously used in the current SAS session or a previous SAS session. (Libraries can be re-assigned by issuing a LIBNAME statement that names the libref with which the library is currently assigned. Certain SAS procedures, the DOWNLOAD procedure in particular, also re-assign libraries.) Moreover, a direct access bound library that is externally allocated with DISP=NEW cannot be re-assigned once the library has been extended to more than one volume, and the library is temporary, not cataloged, or resides in a generation data group (GDG). (However, a library that is allocated with DISP=(NEW,CATLG) can be re-assigned even after it has been extended to multiple volumes.) The restrictions above can be circumvented by establishing a DISP=OLD or DISP=SHR allocation to continue processing the library. Under TSO, the restrictions can be circumvented by deassigning the library, freeing the external allocation, and using the SAS LIBNAME statement or TSO ALLOCATE command to establish a new allocation. In batch, the restrictions can be circumvented by passing the library to a subsequent job step for further processing.
  • Leading blanks on member names are ignored.
  • SAS does not support multi-volume direct access bound libraries with zero DASD extents on the first volume. To avoid this situation, always specify a nonzero primary allocation value when you assign a new direct access bound library that can extend to multiple volumes.
  • Values that are specified for the BUFNO option of the DD statement are ignored. Use the SAS system option BUFNO to tune SAS I/O processing. For more information, see Optimizing Performance and BUFNO= Data Set Option in SAS Data Set Options: Reference.

Controlling Library Block Size

The block size of a direct access bound library affects performance because it is the minimum value for the page size for all SAS files in the library. Moreover, the page size of any SAS file in the library must be an integral multiple of the library block size. For more information, see Optimizing SAS I/O.
The block size of a direct access bound library is set at initialization time, and it does not change for the duration of the library data set. SAS begins the process of determining the library block size by selecting the first applicable value from the following hierarchy of sources:
  • for a preallocated but uninitialized data set, the block size value specified for the first or only volume of the data set.
  • for a data set allocated using DISP=NEW, the block size value specified on allocation, either in the LIBNAME statement or, for external allocation, in the DD statement or TSO ALLOCATE command. For a description of how and when SAS dynamically allocates the library data set, see Allocating the Library Data Set.
  • value of the BLKSIZE= system option, if nonzero.
  • value of the BLKSIZE(device-type) system option for the device type on which the library resides, provided the value is nonzero.
  • 6144.
SAS then adjusts the block size value selected from the list above as necessary to meet the unique requirements of direct access bound libraries. The following procedure is used to adjust the value:
  • If the value is greater than the maximum for the device, it is decreased to the maximum for the device.
  • If the value is less than 4096, it is increased to 4096.
  • After the previous two calculations are completed, if the value is not a multiple of 512, it is rounded down to the nearest multiple of 512.
Note: For example, suppose that a block size of 27,998 (optimal half-track blocking for an IBM 3390) was specified for a given library by one or more of the means listed in this section, and it was specified that the library would reside on a 3390 device. SAS would not use the specified block size. Instead, SAS would set the library block size to 27,648, because that is the largest multiple of 512 that is less than or equal to 27,998.

Sequential Access Bound Libraries

Overview of Sequential Access Bound Libraries

A sequential access bound library is a single z/OS data set that resides on disk or tape and logically contains one or more SAS files, each file written sequentially one after another. The primary purpose of this library implementation, like the sequential engines that it supports, is for storing SAS data sets on sequential devices such as tapes. Moreover, sequential access bound libraries on z/OS are also internally compatible with the sequential format libraries used by SAS on CMS. This compatibility provides a way for SAS data to be interchanged between the two operating environments. Sequential access bound libraries can extend to multiple volumes, subject only to the limitations of the device type.

Creating Sequential Access Bound Libraries

The following example shows how to create a new multivolume tape library that resides on more than five volumes. As the sample JCL DD statement shows, the library can be assigned externally. 
//MYTAPE   DD DSN=USER489.TAPE.SASLIB,DISP=(NEW,CATLG,DELETE),
//         UNIT=CART,LABEL=(1,SL),VOLUME=(PRIVATE,,,7)
The library data set can also be assigned internal to SAS using the SAS LIBNAME statement, as is shown in the following example, which is equivalent to the above DD statement: 
libname mytape tape 'user489.tape.saslib' disp=(new,catlg,delete)
   unit=cart label=(1,sl) volcount=7;
Regardless of how the library data set was assigned (either with a DD statement or with a LIBNAME), specify the libref, or externally assigned ddname, as the library in which a new member is to be created, as is shown in the following example: 
data mytape.member1; /* new member */
...
Note:
  • The engine ID must be specified when you internally assign a new library on tape. However, when you externally assign a new library on tape, the value of the SEQENGINE system option determines the engine that is used to create the library, unless it is overridden by a LIBNAME statement.
  • The volume count must be specified for a tape library that will extend to more than five volumes. Refer to the documentation for the VOLUME parameter of DD statement in IBM MVS JCL Reference for details.
The following example shows how to create a new, multivolume sequential access bound library on disk that uses as many as three volumes. As this sample JCL DD statement shows, the library can be assigned externally: 
//SEQDISK  DD   DSN=USER489.SEQDISK.SASLIB,DISP=(NEW,CATLG),
//         UNIT=(3390,3),SPACE=(CYL,(200,200)),BLKSIZE=27998
...
  LIBNAME SEQDISK TAPE; /* use TAPE engine */
  DATA SEQDISK.MEMB01;
  ...
The library data set can also be assigned internal to SAS using the SAS LIBNAME statement, as shown in the following example, which is equivalent to the DD statement above: 
libname seqdisk tape 'user489.seqdisk.saslib' disp=(new,catlg)
   unit=(3390,3) space=(cyl,(200,200)) blksize=27998;
data seqdisk.memb01;
...
Note:
  • To ensure the most complete use of the DASD track, specify the optimum half-track BLKSIZE for the type of disk device used. For sequential access bound libraries, this value must be specified in the DD or LIBNAME statement. The SAS BLKSIZE system options are not used for sequential access bound libraries.
  • The maximum number of disk volumes to which the library data set can extend is governed by the unit count in the examples above.
  • Sequential access bound libraries can reside in extended format sequential data sets. Extended format sequential data sets can be defined as compressed by SMS, and they can also occupy more than 64K tracks per volume.

General Usage Notes

  • Due to the nature of sequential devices, SAS allows only two types of operations with members of a sequential bound library: reading an existing member and writing a new copy of a member to the library. The following types of operations are not supported for sequential access bound libraries:
    • having multiple members in the library open at the same time
    • updating the contents or attributes of a member of the library
    • renaming or deleting a member of the library.
CAUTION:
SAS deletes all members of a sequential bound library that are subsequent to the library member that you replace.
  • By default, when writing a member of a sequential bound library, SAS scans the entire library from the beginning to determine whether a member having the specified name already exists in the library. If such a member already exists in the library, then the new copy of the member is written starting at the position in the library data set where the old copy of the member began, and all subsequent members of the library are deleted. If the specified member does not already exist in the library, it is appended to the end of the library. This behavior is not influenced by the REPLACE system option because NOREPLACE is not supported by the TAPE engine.
  • When the FILEDISP=NEW data set option is specified for a member to be written to a sequential access bound library, SAS replaces all of the members that previously existed in the library, even if they were protected by an ALTER password. The ALTER password is not checked even for the member being replaced.
  • When the COPY procedure is used to write members to a sequential access bound library, the rules regarding member replacement (listed above) apply only to the first member being processed by a COPY statement or PROC COPY invocation. All other members involved in the COPY operation are appended to the end of the library data even if they already exist in the library. Therefore, it is possible to cause a library to contain two copies of the member, only the first of which will be recognized. You should plan all COPY operations carefully so that you avoid this outcome.
  • Some specialized SAS procedures repeatedly process a group of observations that have the same value for a specific variable. This situation requires SAS to interrupt its sequential access pattern and reposition to a previous location in the library data set. However, SAS does not support repositioning to a location on a previous volume of a multi-volume tape data set. When this situation occurs, SAS will issue the following error message: 
    ERROR: A POINT operation was attempted on sequential library SEQLIB.
   A volume switch has occurred on this library since the last NOTE
   operation, making the POINT results unpredictable.
    Should this situation occur, you can avoid the limitation by copying the member to a library on disk.
  • When using the LIBNAME statement to dynamically allocate SAS libraries on tape, it is not possible to simultaneously allocate multiple MVS data sets on the same tape volume. Therefore, it is necessary to use the SAS LIBNAME CLEAR statement to deassign the library before you attempt to assign another MVS data set on the tape.
  • The mode in which SAS opens the library data set is primarily governed by the type of access that is being performed. When reading a member, listing the members in the library, or retrieving information about the library, the library data set is opened for INPUT. When writing a member, the library data set is opened for INOUT (unless DISP=NEW and the data set has not been previously opened. In that case OUTIN is used). SAS will not write to a library allocated with DISP=SHR or LABEL=(,,,IN), issuing an ERROR message instead. Before opening the library data set, SAS will first check the RACF authorization, but only for libraries which reside on disk, and only if NOFILEAUTHDEFER is in effect.

Optimizing Performance

  • SAS locates members of sequential access bound libraries by sequentially scanning the library from the current location (usually the beginning of the library data set) until the member is located. Depending on the tape device hardware and the position within the tape library of the members being read, a significant amount of elapsed time can be consumed by tape positioning. If many members are read, or if some members are read repeatedly, the total I/O and elapsed time required by the job can be reduced by invoking PROC COPY to selectively copy members of interest from the tape library to a Base engine SAS library. The members of interest can then be read from the Base engine library without incurring delays for tape positioning. The savings in elapsed time can be particularly significant for multi-volume libraries due to the avoidance of extra tape mount requests. This technique can also be valuable for sequential access bound libraries on disk.
  • When adding members to an existing sequential access bound library on tape, SAS can read the library to determine which engine format to use. However, determining the engine format requires an extra tape mount if the library is internally assigned. By explicitly specifying the engine, you can avoid this extra tape mount.
  • To release the library data set before the end of the SAS session, specify the SAS TAPECLOSE=FREE system option before the SAS DATA step or procedure that writes the members of the library. For tape libraries, this step is necessary to make the tape device and volumes available for other jobs before the end of the SAS session.
  • In some cases, it is convenient to create multiple tape libraries on the same tape volume. To avoid having the operating system unmount and re-mount the tape volume for each library data set, allocate the libraries via JCL DD statements that specify UNIT=AFF and VOLUME=(,RETAIN,REF=<ddname>), as the following example shows: 
    //jobname JOB job-accounting-info
//* -------------------------------------------------------------------
//* create multiple sequential libs stacked on single tape volume
//* -------------------------------------------------------------------
//SAS      EXEC SAS
//SASLOG   DD   SYSOUT=*
//SASLIST  DD   SYSOUT=*
//TAPLIB01 DD   DSN=USERA.TAPELIB1,DISP=(NEW,CATLG,DELETE),
//         UNIT=(CART,,DEFER),
//         LABEL=(1,SL),VOLUME=(PRIVATE,RETAIN)
//TAPLIB02 DD   DSN=USERA,TAPLIB2,DISP=(NEW,CATLG,DELETE),
//         UNIT=AFF=TAPLIB01,
//         LABEL=(2.SL),VOLUME=(PRIVATE,RETAIN,REF=*.TAPLIB01)
//TAPLIB03 DD   DSN=USERA.TAPLIB,DISP=(NEW,CATLG,DELETE),
//         UNIT=AFF=TAPLIB01,
//         LABEL=(3,SL),VOLUME=(PRIVATE,RATAIN,REF=*.TAPLIB01)
//SYSIN    DD *
  data taplib01,memb01;
  ...
  run;

  data taplib02.memb02;
  ...
  run;

  data taplib03.memb03;
  ...
  run;
/*
//
  • When attempting to read multiple SAS libraries that reside on the same tape volume, specifying the SAS system option TAPECLOSE=LEAVE can significantly reduce the elapsed time required for the job. TAPECLOSE=LEAVE causes the operating system to leave the tape volume positioned at the end of the library data set when it is closed. Otherwise, the operating system rewinds to the beginning of the library data set and then advances to the next library data set. Those two redundant operations could require significant elapsed time. The following sample job reads the three data libraries that are created by the preceding example. 
    //jobname JOB job-accounting-info
//*
//SAS      EXEC SAS
//SASLOG   DD   SYSOUT=*
//SASLIST  DD   SYSOUT=*
//TAPLIB01 DD   DSN=USERA.TAPELIB1,DISP=SHR
//TAPLIB02 DD   DSN=USERA.TAPELIB2,DISP=SHR
//TAPLIB03 DD   DSN=USERA.TAPELIB3,DISP=SHR
//SYSIN    DD *
  options tapeclose=leave;
  data _null_;
     set taplib01.memb01;
  run;

  data _null_;
     set taplib02.memb02;
  run;

  data _null_;
     set taplib03.memb03;
  run;

/*
//

Controlling Library Block Size

Because sequential access bound libraries use RECFM=U, the block size value is an upper limit for the maximum size of a block. The value that SAS uses for any given session, for either a new or existing library, is specified by the user from the following hierarchy of sources:
  • the block size value specified on allocation, either in the LIBNAME statement or, for external allocation, in the DD statement or TSO ALLOCATE command
  • the block size value specified in the data set label, that is, the value specified on the DISP=NEW allocation that created the data set
  • 32760

UFS Libraries

Overview of UFS Libraries

A UNIX file system (UFS) library is a collection of SAS files of the same engine type that is stored in a single directory of the z/OS UNIX System Services (USS) file system. Each SAS library member resides in a separate UFS file. UFS is a default component of z/OS, and its availability is limited only by the extent to which it has been implemented at a particular installation.
Note: In addition to the original UFS implementation, z/OS also provides another UNIX file system known as zFS. zFS, which provides certain performance and manageability benefits, is functionally equivalent to UFS from the perspective of a SAS user. All information about UFS libraries applies equally to SAS files that reside in a zFS file system. Your system administrator, not SAS, controls whether the UFS or zFS implementation is used for a particular file system.
UFS libraries provide many important capabilities that are not available in other types of library implementations:
  • Members of UFS libraries can be processed by versions of SAS running in other operating environments via the SAS cross-environment data access (CEDA) facility. The individual SAS files can be copied (via a utility such as FTP) to other operating environments and can be directly read by the versions for the target operating environment. Conversely, SAS files created in most other operating environments can be copied to a UFS directory and read directly by the z/OS version of SAS via CEDA. This technique can be further extended by using the network file system (NFS) capability of z/OS to either mount directories that exist on remote hosts (NFS client) or to share a UFS directory with other hosts (NFS server).
  • UFS directory names can contain mixed case, and they can also be longer than a z/OS data set name. The directory hierarchy provides more flexibility for organizing files.
  • Multiple SAS jobs can simultaneously update different members of the same library. This capability provides more flexibility than that of direct access and sequential access bound libraries, which only permit one SAS job to have update access to a library at a given time.
  • Allocating and assigning a UFS library is very straightforward. The LIBNAME statement merely needs to specify the libref, the USS directory path, and perhaps the engine. The various options for reserving space and specifying DCB attributes are not required, nor do they apply to UFS libraries.

Creating UFS Libraries

Creating a UFS library is as simple as creating a SAS file in a particular library directory, as shown in the following example: 
libname myproj '/u/user905/MyProject';
data myproj.member1;
   ...
run;
If the library directory does not exist, SAS automatically creates the directory if possible. In the example above, the directory node MyProject would have been created if it did not already exist, provided the SAS session had adequate authority to do so. However, the other directories in the directory path must exist before you attempt to create the library.

General Usage Notes

  • The fully qualified name of a SAS file in a UFS library is
    <fully-qualified-path>/<member-name>.<SAS-extension>
    The member name in this construction is formed by converting to lowercase the member name specified in the SAS session. The filename extension for a SAS file is automatically supplied by SAS and indicates the member type and the engine that was used to create the file. For a list of extensions that are used, see File Extensions for SAS Files in UFS Libraries. Do not change the filename extension of a SAS file because that could cause unpredictable results. The total length of the fully qualified name must not exceed 254 characters. This value is more restrictive than the IBM limits on UFS filenames.
  • When SAS creates or updates a member of a UFS library, it places an exclusive lock on the individual file (but not on the library). The lock prevents other jobs, processes, or SAS sessions from reading, writing, or updating that file until SAS finishes using the file, at which time the lock is removed. It is still possible for other SAS sessions to access other SAS files in the library, provided they are unlocked. The write lock is analogous to the SYSDSN enqueue that is issued when a data set is allocated with DISP=OLD.
  • When SAS reads an existing member of a UFS library, it places a read (or shared) lock on the individual file. This lock prevents other jobs, processes, or SAS sessions from updating the file, although it is still possible for others to read the file. The read lock is analogous to the SYSDSN enqueue that is issued when a data set is allocated with DISP=SHR.
  • In performance testing at SAS, native UFS libraries have demonstrated I/O throughput rates that, for a variety of access patterns, generally match or exceed the rates demonstrated for direct access bound libraries.
  • Although it is possible to externally allocate a UFS library via JCL or the TSO ALLOCATE command, doing so does not lock or reserve the library in any way. The main benefit of external allocation is to provide a convenient way to specify a different library for a particular job.
  • When using NFS client capability to access SAS files in other operating environments, specify the xlat(n) option for the NFS mount point on z/OS. Similar options might need to be specified in other operating environments when you are accessing SAS files shared by an NFS server running on z/OS. For information about the xlat option, see the IBM documentation for the z/OS Network File System (NFS).
File Extensions for SAS Files in UFS Libraries
Random Access Files
Sequential Access Files
SAS Member Type
Description
.sas7bdat
.sas7sdat
DATA
SAS data file
.sas7bndx
.sas7sndx
INDEX
data file index; not treated by SAS software as a separate file
.sas7bcat
.sas7scat
CATALOG
SAS catalog
.sas7bpgm
.sas7spgm
PROGRAM
stored program (DATA step)
.sas7bvew
.sas7svew
VIEW
SAS data view
.sas7bacs
.sas7sacs
ACCESS
access descriptor file
.sas7baud
.sas7saud
AUDIT
audit file
.sas7bfdb
.sas7sfdb
FDB
consolidation database
.sas7bmdb
.sas7smdb
MDDB
multidimensional database
.sas7bods
.sas7sods
SASODS
output delivery system file
.sas7bdmd
.sas7sdmd
DMDB
data mining database
.sas7bitm
.sas7ssitm
ITEMSTOR
item store file
.sas7butl
.sas7sutl
UTILITY
utility file
.sas7bput
.sas7sput
PUTILITY
permanent utility file
.sas7bbak
.sas7sbak
BACKUP
back up file

Hiperspace and DIV Libraries

Overview of Hiperspace and DIV Libraries

A hiperspace library is a temporary library in which each library block resides in a 4K block in a z/OS hiperspace, a form of electronic storage internal to the processor. The hiperspace facility can be exploited for permanent data by defining a data-in-virtual (DIV) library in which the library blocks are loaded into the hiperspace for processing and saved permanently in a VSAM linear data set. Hiperspace and DIV libraries have the same internal format as that of a direct access bound library, and SAS automatically re-uses free space within the library.
Placing small to moderately sized SAS data sets in a hiperspace or DIV library can dramatically decrease the elapsed time required for SAS to process such data sets. The performance increase is usually at least as great as for direct access bound libraries allocated to VIO and is particularly significant for data sets that are accessed randomly. However, the actual performance benefit depends on various factors, including the amount of z/OS expanded storage available to the SAS session. These benefits occur by default for hiperspace libraries, but the SAS system option NOHSSAVE must be specified in order to achieve the increase in I/O throughput for DIV libraries. When specifying NOHSSAVE, design your SAS application carefully to ensure that updates stored in the DIV library can be re-created, which might be needed if certain types of abends occur. For information about the NOHSSAVE SAS system option, see HSSAVE System Option: z/OS.
The number of hiperspace pages used for hiperspace and DIV libraries is governed by the HSLXTNTS, HSMAXPGS, and HSMAXSPC SAS system options. When a hiperspace or DIV library is created, a hiperspace with HSLXTNTS pages is created. When the library needs to be extended, another hiperspace is established with that same number of pages. This process can continue until a total hiperspace in use by SAS in the current session for all hiperspace/DIV libraries exceeds HSMAXSPC, or the total number of hiperspace pages in use by SAS the current session for all hiperspace/DIV libraries exceeds HSMAXPGS. For DIV libraries, the amount of disk space specified (by you or by default) must also be sufficient to contain the number of 4K blocks to which the library extends. For more information about these SAS system options, see HSLXTNTS= System Option: z/OS, HSMAXPGS= System Option: z/OS, and HSMAXSPC= System Option: z/OS.

Creating Hiperspace Libraries

These sample statements demonstrate how to create a temporary hiperspace library: 
libname hiperlib '&temp' hip;
data hiperlib.memb01;
   ...
run;
Because of the requirements of the LIBNAME statement, a library physical name must be specified. A temporary data set is allocated, but it is not used.
The following example demonstrates how to create a DIV library using JCL: 
//          JOB
//* HIPERSPACE LIBRARY BACKED BY VSAM LINEAR DS (DIV)
//         EXEC SAS
//DIVLIB   DD   DSN=USER489.DIV.SASLIB,
//         DISP=(NEW,CATLG),SPACE=(CYL,(5,5)),
//         RECORG=LS
//SYSIN    DD *
  LIBNAME DIVLIB '' HIP;
  DATA DIVLIB.MEMB01;
     ...
  RUN;
//
The RECORG=LS parameter is necessary at creation time to ensure that the DIV library data set is properly allocated. However, no special options are required to assign an existing DIV library. The following example shows how to create the same DIV library using the LIBNAME statement: 
libname div 'user489.div.saslib' linear disp=(new,catlg) space=(cyl,(5,5));

libname divlib 'USER489.DIV.SASLIB';
proc contents data=divlib._all_; run;
See the following system options for information about controlling how SAS processes hiperspace libraries:

Pipe Libraries

Overview of Pipe Libraries

The IBM product BatchPipes on z/OS provides a way to reduce the elapsed time for processes in which one job creates a data set that is read by a second job in the process. SAS supports the use of BatchPipes with SAS data sets that were created with the TAPE and V6TAPE engines. With BatchPipes, each page of a SAS data set written to a pipe can be read immediately by a second SAS session. Because the second session does not have to wait for the entire data set to be written, the two SAS sessions can run largely in parallel, subject to available system resources. The resulting increase in throughput can be particularly important for sequences of batch jobs that must complete within a certain time frame.
In order to use BatchPipes on z/OS, verify that the BatchPipes product is installed and that at least one instance of the BatchPipes subsystem is started. Second, consult the IBM documentation, particularly the IBM BatchPipes z/OS Users Guide and Reference, for general background on how to use the product.
Using SAS with BatchPipes requires two jobs, one that writes a SAS data set into the pipe and a second that reads the data set from the pipe. Both sending to, and receiving from, a pipe are inherently sequential operations, so only the V9TAPE engine or the V6TAPE engine can be used. SAS generally treats the pipe as a special type of sequential access bound library, with additional exceptions and restrictions noted below.

General Usage Notes

  • The pipe library must be allocated external to SAS either for output (meaning that SAS is sending member contents to another job) or for input (meaning that SAS is receiving member contents from another job). The section below describes in detail how to allocate pipe libraries. It is not possible to dynamically allocate a pipe library (via the LIBNAME statement), so it is not possible during a SAS session to change the manner (that is, sending or receiving) in which the pipe library is being used.
  • Only one member can be written to a pipe library by a single DATA step or SAS procedure. Likewise, one pipe library member can be read by a single DATA step or SAS procedure. It is possible, however, to transfer multiple members between jobs by pairing each sending step or procedure in one job with a receiving step or procedure in a second job. A single member is transferred by each pair with this process.
  • Only output SAS operations can be attempted on the sending side of a pipe, which is consistent with the nature of pipes. Therefore, the job that has allocated a pipe library format should not attempt to use PROC CONTENTS to list the library directory. Likewise, only input SAS operations should be attempted on the receiving side of a pipe library. Moreover, since the pages in the pipe are transient (that is, they exist only until they are read by the receiving job), it is not possible to re-read a previously read member or to list the directory after the library has already been read.
  • SAS does not support a mode of operation in which there are multiple readers or multiple writers for a pipe library. For example, using two different jobs to simultaneously write to a pipe that is being read by another SAS job would lead to errors, incorrect results, or both.
  • It is important to monitor and verify that pipe-related jobs are running as expected. Under normal circumstances, the receiving SAS DATA step or procedure reads all of the member pages sent by the sending SAS DATA step or procedure. After sending the last member page, the sending step or procedure closes the pipe library, and the receiving step or procedure receives an end-of-file indication after reading the last member page. However, if the receiving step or procedure encounters an error condition (such as out-of-space on a library or external file to which it is copying the member data), the receiving step or procedure closes the pipe library before it has read all the member pages that the sending step or procedure has sent (or will send). To avoid the sending job suspending indefinitely in this case, specify the option ERC=DUMMY on the SUBSYS parameter of the DD statement for the sending job. If the receiving step or procedure closes the pipe library prematurely, the ERC=DUMMY option causes the sending STEPOR procedure to continue processing. In this case, the member pages are discarded instead of being sent to the receiving job.
  • If you receive a message that the PIPE command was stopped, contact your systems administrator. You might need to update your profile. For information about determining the minimum requirements that are needed to use the pipe engine, see the Configuration Guide for SAS 9.2 Foundation for z/OS.

Allocating a SAS Library to a Pipe

  • Externally assign the pipe library using a JCL DD statement. On this DD statement, use the SUBSYS parameter to specify the name of the BatchPipes subsystem that manages the pipe. Within the SAS job, refer to this pipe library using the ddname specified as the libref. Specify the DSN parameter in the DD statement using a data set name that conforms to the standards for your installation.
  • Distinguish between the sending and receiving sides of the pipe library using the LABEL parameter of the DD statement. In the DD statement for the pipe library, specify LABEL=(,,,OUT) whether SAS will send SAS data sets to the pipe library. Specify LABEL=(,,,IN) if SAS will read SAS data sets from the pipe library.
  • The DCB attributes for a pipe library vary from the DCB attributes used for other sequential access bound libraries. Specify DSORG=PS, RECFM=F for both the sending and receiving sides of the pipe library. Specify an LRECL between 1024 and 32760 for the pipe library. The values specified for LRECL in the sending and receiving sides of the pipe library must match exactly.
  • Identify, if necessary, the engine to be used for processing the pipe library. By default, SAS uses the value of the SEQENGINE option to determine the engine to use for processing the pipe library. If this value is appropriate and set identically for both the sending and receiving jobs, it is not necessary to identify the engine. To use another engine, specify a LIBNAME statement with the libref and engine and no other parameters.
  • No other DD statement parameters other than those described in this section should be specified unless they are described in the IBM documentation.

Sample JCL

The following code example illustrates how to write a SAS library to a pipe: 
//jobname JOB
    // EXEC SAS
    //*--------------------------------------------------
    //* This job writes a SAS data set to a pipe.
    //*--------------------------------------------------
    //PIPESND DD DSN=TEST.SAS.BATCHPIPES,
    // LRECL=6144,RECFM=F,DSORG=PS,
    // SUBSYS=(BP01,CLOSESYNC,ERC=DUMMY),
    // LABEL=(,,,OUT)
    //*
    //SYSIN DD *
      data pipesnd.member1;
         ...
         output;
      run;
    /*
    //
The following code example illustrates how to read a SAS library from a pipe: 
//jobname JOB
    // EXEC SAS
    //*-------------------------------------------
    //* This job reads a SAS data set from a pipe.
    //*-------------------------------------------
    //PIPERCV DD DSN=TEST.SAS.BATCHPIPES,
    // LRECL=6144,RECFM=F,DSORG=PS,
    // SUBSYS=(BP01,CLOSESYNC,EOFREQUIRED=NO),
    // LABEL=(,,,IN)
    //*
    //SYSIN DD *
      data ...;
         set pipercv.member1;
         ...
      run;
    /*
    //
The following code examples demonstrate how to use multiple SAS DATA step or procedure pairs in a single pair of jobs. Note that only one member can be written to a pipe library in a SAS step, and that there is a one-to-one correspondence of steps and procedures between receiving and sending pipe jobs.
Sending job: 
DATA PIPEOUT.MEMBER1; X=1; RUN;

DATA PIPEOUT.MEMBER2; Y=2; RUN;
Receiving job: 
/* receives MEMBER1 from sending job */
DATA X; SET PIPEIN.MEMBER1; RUN;

/* will copy MEMBER2 to WORK library: */
PROC COPY IN=PIPEIN OUT=WORK; RUN;
Copyright © SAS Institute Inc. All rights reserved.