SAS/C Software: Changes and Enhancements, Release 6.50

New Access Method Parameters (amparms)

This section describes the new file usage amparms for Release 6.50.

The share=ispf amparm

The share=ispf amparm allows a program to write to an ISPF member without allocating the entire dataset as "OLD". Other programs can continue to read and write to other members while the program updates the designated member.

Here is an example:

int cardfd;
cardfd = aopen("dsn:sas.test.c(hello)", 
               O_RDWR, "share=ispf");

Note: Opening a file with the share=ispf amparm allows a PDS to be shared by several programs or users but must be used carefully.

Using share=ispf allows a PDS to be allocated as SHR and used by cooperating programs, that is, by the ISPF editor and utilities, by other SAS/C programs which open specifying share=ispf, and by any other applications which observe the ISPF protocols.

Using share=ispf does not prevent access by applications that do not observe the ISPF protocols. Such access may cause file damage or loss of data.

While a SAS/C program has a PDS member open with share=ispf, an attempt by an ISPF user to save another member of the same PDS will wait until the SAS/C program closes the member. Similarly, when one SAS/C program has a PDS member open using share=ispf, any other SAS/C program which opens the same PDS with share=ispf will wait until the first program closes its member. For this reason, programs which use share=ispf should be designed to keep such files open for as small an interval of time as possible. [cautend]

The share=alloc amparm

The share=alloc amparm is used to open a new or existing file by DSN as shared. Here is an example:

int cardfd;
cardfd = 
  aopen("dsn:sas.test",
        O_CREAT | O_RDWR | O_APPEND,
       "recfm=f,reclen=80,share=alloc");

CAUTION:: When you open a file using the share=alloc amparm, the operating system and the C library offer little protection against file damage or loss of data if several programs write to the file at the same time. Some versions of MVS will ABEND a program which attempts to write to a PDS that another program has opened; however, no protection at all is available for sequential data sets. For this reason, the share=alloc amparms should be used only when there is no risk of multiple simultaneous access, when the program itself synchronizes access to the file ( for example, using the MVS ENQ macro, or where the risk of occassional loss of data or file damage is considered acceptable.

Record Level Sharing (rls) amparms

shr=rls

specifies the use of VSAM Record Level Sharing protocols for processing the dataset.

shr=rlsread

specifies the use of VSAM Record Level Sharing protocols for processing the dataset and specifies their use for nonupdate file accesses.

Note: Many of the sharing pitfalls can be prevented by used of VSAM Record Level Sharing (RLS) support available for MVS with DFSMS Version 1, Release 3 or higher. Also, with VSAM, RLS locking is done at the record level as opposed to the control interval. [cautend]

The share=rls or share=rlsread amparm specifies that VSAM record level sharing protocols are to be used for processing the dataset. The RLS protocols are available for MVS only with DF/SMS Version 1, Release 3 (or higher) installed or OS/390 Release 2, which includes it. In addition, using the RLS feature requires supporting hardware (SYSPLEX Coupling Facility (CF)) and proper site installation configuration of DF/SMS.

This option is meaningful only for VSAM files and is equivalent to coding MACRF=(RLS) for share=rls or MACRF=(RLS), RLSREAD=CRI for share=rlsread on an ACB assembler macro used to open the VSAM file. RLS implies the use of cross-system record level locking as opposed to CI locking, uses CF for cross-system buffer consistency with a coordinated system wide local buffer cache. The amparm share=rlsread also specifies that consistent read integrity (record locking during all reads) be used for read requests, even if the dataset is opened for read only ( mode=r) or K_noupdate flag is specified with kretrv. Specifying share=rlsread overrides any RLS JCL specification. VSAM RLS supports only cluster or path level access (that is, no individual data, index, or alternate index component access) and does not support linear datasets or datasets which are defined with an imbedded index or a keyrange. Recoverable datasets, that is, datasets defined with the IDCAMS LOG(UNDO) or LOG(ALL) attribute, can only be opened for read ( mode=r) because of the CICS file control and logging requirements. Nonrecoverable datasets, that is, LOG(NONE), or the default can be opened in any mode with the LOG(NONE) attribute since no CICS file control or logging is required for these datasets.

share=rls or share=rlsread causes VSAM to ignore any bufnd/bufni/bufsp specification. However, in general, the VSAM RLS feature is transparent from a C library VSAM file function acces usage standpoint since the protocols are implemented at the operating system level and not in the library except for specifying the ACB options. However, a couple of pitfalls are worth mentioning. File opens with VSAM RLS will fail if there are nonRLS users of the dataset, and conversely nonRLS opens will fail if there are RLS users of the dataset. While MVS recovery is usually satisfactory, it is possible through system crashes and/or abends that it leaves the dataset locked out from nonRLS access, and locked records unavailable to RLS users until the IDCAMS utility is called to fix it.

Chapter Contents
Previous
Next
Top of Page