Processing CMS Minidisk Files

A GCS program processes CMS minidisk files using BSAM or QSAM macros. For GCS, these macros have unique constraints. In particular, GCS's data management service supports only the extended file system format.

GCS's QSAM/BSAM data management service supports the following command:

FILEDEF: Defines CMS minidisk files and CP spool files.

GCS data management supports the following set of macros, at the MVS/SP 1.3.1 level:

CHECK: Wait for and test completion of a read or write operation (BSAM).
CLOSE: Logically disconnect a file (BSAM and QSAM).
DCB: Construct a data control block (BSAM and QSAM).
DCBD: Provide symbolic reference to data control blocks (BSAM and QSAM).
GET: Obtain next logical record (QSAM).
NOTE: Determine relative position (BSAM).
OPEN: Logically connect a file (BSAM and QSAM).
POINT: Point to the relative position of a specific block (BSAM).
PUT: Write next logical record (QSAM).
READ: Read a block (BSAM).
SYNADAF: Perform SYNAD analysis function (BSAM and QSAM).
SYNADRLS: Release SYNADAF buffer and save areas (BSAM and QSAM).
WRITE: Write a block (BSAM).

Unlike CMS's data management service, it does not allow:

Files that reside in a CMS Shared File System file pool
OS formatted files
File mode 4 (treated instead like file mode 1)
Spanned records
Console or tape I/O
Utility functions (like formatting disks, loading files from tape, editing files, and others).

GCS's data management does follow the same rules as CMS's when two or more virtual machines want to share the same disk. Read/write privileges go to only one virtual machine at a time, while multiple disk and minidisk users must share in read-only mode. For more information on disk sharing, see z/VM: CMS User's Guide.

Sometimes two or more tasks within the same machine need to share a single file. They can do this under two conditions:

If they concurrently open and use multiple Data Control Blocks (DCBs) that refer to the same, shared file.

When many DCBs refer to a single file, the type of processing (input, output, or update) decides what programming procedures you should use. Table 1 shows you the different types of processing and the requirements that go along with each.

Table 1. Opening Multiple DCBs
Type of processing:	Programming required:
INPUT	Each task should issue READ and GET requests as if no file sharing were taking place. GCS keeps track of the read pointers.
OUTPUT	This sort of sharing is not supported for multiple DCBs. Unpredictable results will occur if you attempt it.
UPDATING (in BSAM)	Each task should issue ENQ before the READ macro. This helps serialize the processing of each block of records. Macros issued to complete the update are WRITE, CHECK, and DEQ, in that order. For more information on these macros, see WRITE (BSAM), CHECK (BSAM), and DEQ.
UPDATING (in QSAM)	When updating a file, a task must avoid altering blocks containing records that other tasks are updating. GCS has no way of knowing whether different tasks are processing discrete blocks.

Note: When you share a file with multiple DCBs, be sure you enter the FILEDEF command only once for each ddname. If you need to enter FILEDEF for the same ddname and same file later in the program, make sure you specify the NOCHANGE option. See FILEDEF.

If they concurrently open and use only one shared DCB.
When tasks share a single DCB, GCS permits all three types of processing (inputting, outputting, and updating). However, tasks have to use the ENQ and DEQ macros to coordinate their activities. (See Coordinating Shared Resources.) Because only one of them can have control at a time, the tasks must issue the ENQ macro first (to take turns at getting control) and end with the DEQ macro (to release control).