Browse Prior Art Database

Shared Direct Access Storage Device Support Improvement

IP.com Disclosure Number: IPCOM000075280D
Original Publication Date: 1971-Aug-01
Included in the Prior Art Database: 2005-Feb-24
Document File: 5 page(s) / 98K

Publishing Venue

IBM

Related People

Jacobs, PC: AUTHOR

Abstract

The IBM System/360 Operating System (with the Shared DASD Option) allows the sharing of data sets between CPUs, but requires the user to issue the RESERVE macro to protect his data set from inadvertent alteration by another CPU. The RESERVE macro prevents another CPU (that is connected to the same device) from accessing that volume until a corresponding DEQ macro is issued by the "reserved" user. It is not possible therefore, to concurrently read/write different data sets located on the same volume (by more than one CPU).

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 5

Shared Direct Access Storage Device Support Improvement

The IBM System/360 Operating System (with the Shared DASD Option) allows the sharing of data sets between CPUs, but requires the user to issue the RESERVE macro to protect his data set from inadvertent alteration by another CPU. The RESERVE macro prevents another CPU (that is connected to the same device) from accessing that volume until a corresponding DEQ macro is issued by the "reserved" user. It is not possible therefore, to concurrently read/write different data sets located on the same volume (by more than one CPU).

The described improvement will allow two or more CPUs to read/ write data sets located on the same volume concurrently. This method has significant performance advantages over the current method, because the RESERVE macro is not issued except to protect the Volume Table Of Contents (VTOC) during OPEN/CLOSE/END OF VOLUME time. After a data set has been opened, it will be possible to access any data set freely.

A data set (DS) can have one of two sharability modes; (1) Sharable, and (2) Exclusive. To qualify for the Sharable mode, the processing mode must be READ-ONLY. If records are being added, updated, or deleted from the data set, the sharability mode is Exclusive. An Exclusive Mode Data Set (EMDS) cannot be shared between CPUs. A non-EMDS can be shared between CPUs and within CPUs.

Each format 1 Data Set Control Block (DSCB-1) will contain an EMDS bit and a Data Set User Count (DSUC) field. The EMDS bit is set to 0 to indicate the Sharable mode and set to 1 to indicate Exclusive mode. The DSUC contains the number of users currently opened on the DS. The format 4 DSCB (DSCB-4) will contain a new field, Volume User Count (VUC), to contain the total number of users on the volume. The VUC will contain the sum of all DSCB-1 DSUC and must be 0's before the volume can be dismounted.

Fig. 1 illustrates a shared DASD volume that contains six opened data sets and is being shared by three CPUs (CPU-A, CPU-B, and CPU-C). Data set 'JOE' has a DSUC of 1 and the EMDS is 1 (Exclusive mode). If CPU-B or CPU-C attempt to OPEN data sets 'JOE' or 'DAN', the attempt would fail because they are in Exclusive mode. Likewise, data set 'BILL' could not be opened by CPUs A or C. CPU-C would be allowed to open data set 'PAYROLL' for READ-ONLY processing, but not for non-READ-ONLY processing. Unopened data sets could be opened for Sharable or Exclusive mode.

In addition to current functions performed by OPEN, new logic must be incorporated to protect the VTOC while being updated with user counts and setting the EMDS bit. This logic would not necessarily be contained in one module, but interspersed where required. Fig. 2 contains this new logic ignoring all current OPEN functions to clarify the shared DASD logic. The steps in OPEN would be as follows:
Step 1 Test if the data set resides on a shared DASD volume and if so, continue to step 2. If not, bypass shared

1

Page 2 of 5

DASD logi...