Previous Page | Next Page

Using SAS Libraries

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 below. 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

Direct Access Bound Libraries

A direct access bound library is a single z/OS data set, accessed on disk or hiperspace, that 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 that 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:

Default Library Options for the LIBNAME Statement

libname study '.study1.saslib' disp=(new,catlg);
data study.run1;

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:

External Assignment Using JCL

//jobname JOB ...
data study.run1;

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:

External Assignment Using JCL to Specify a Compatibility Engine

//jobname JOB ...
//       UNIT=3390,SPACE=(CYL,(10,10)),
//       DCB=(DSORG=PS,BLKSIZE=27648)
libname hist V6;
data hist.analysis;

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

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. See Optimizing SAS I/O for more information.

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:

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:

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.  [cautionend]

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 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, thus providing 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.


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 */



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:

//         UNIT=(3390,3),SPACE=(CYL,(200,200)),BLKSIZE=27998
  LIBNAME SEQDISK TAPE; /* use TAPE engine */

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;



General Usage Notes

SAS deletes all members of a sequential bound library that are subsequent to the library member that you replace.   [cautionend]

Optimizing Performance

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:

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.  [cautionend]

UFS libraries provide many important capabilities that are not available in other types of library implementations:

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;

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

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. See HSSAVE System Option: z/OS for information about the NOHSSAVE SAS system option.

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. See, HSLXTNTS= System Option: z/OS, HSMAXPGS= System Option: z/OS, and HSMAXSPC= System Option: z/OS for more information about these SAS system options.

Creating Hiperspace Libraries

These sample statements demonstrate how to create a temporary hiperspace library:

libname hiperlib '&temp' hip;    
data hiperlib.memb01;            

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 
//         EXEC SAS
//         DISP=(NEW,CATLG),SPACE=(CYL,(5,5)),
//         RECORG=LS
//SYSIN    DD *

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. Since 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

Allocating a SAS Library to a Pipe

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.
    // LABEL=(,,,OUT)
    //SYSIN DD *
      data pipesnd.member1;

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.
    // LABEL=(,,,IN)
    //SYSIN DD *
      data ...;
         set pipercv.member1;

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:



Receiving job:

/* receives MEMBER1 from sending job */

/* will copy MEMBER2 to WORK library: */             

Previous Page | Next Page | Top of Page