Five routines are invoked to perform OPEN functions, DftSOPL, DeSOR1, DMSOR3, and DMSBOP. DMSCLS perforas the CLOSE function.
Depending on the type of OPEN .acro issued from a user program, one of
five CMS/DOS OPEN routines could be invoked. OPENR macros give control
to DMSOR1 and, depending on the DTF type specified, DMSOR2 or DMSOR3 .ay be invoked. These three routines (DMSOR1,DMSOR2, and DftSOR3) request
the relocation of a specified file. DMSOPL is invoked by the DOS/VS coapilers when they need access to a source statement library. These
routines are mainly interface routines to DMSBOP, which performs the
.ain function of opening the specified file. Each of the routines calls DMSBOP. DMSBOP is the eMS/DOS routine that simulates the DOS/VS OPEN function. The basic function of DMSBOP is the initialization of DTF
tables (that is, setting fields in specified DTFs for use by the DOS/VS LIOCS routines). When a DOS problem program is compiling, a list of DTFs and ACBs is
built. At execution time, this list is passed to DMSBOP. The logic
flow of DMSBOP is as follows:
1. Scans the list of DTF and ACB addresses, handling each iteaa in the
list in line. When the OPEN macro expands, register i points to
the name of the SSB transient to receive control ($$BOPEN) and
register 0 Foints to the list of DTF/ACB addresses to be opened.
2. When an ACB is encountered in the table, control is passed directly
to the VSAM OPEN routine, $$BOVSAM. The VSIM routine is
responsible for opening the file and returning control to DMSBOP. 3. When a DTF is encountered in the table, DMSBOP itself handles the OPEN: a. For reader/punch files (DTFCD), the OPEN bit in the DTF table
is turned on.
b. For printer files (DTFPR), if two IOAREAs are specified, the IOREG is loaded with the address of the appropriate IOIREI. Next, the PUB index byte associated with the logical unit
specified in the DTF is checked to ensure that a physical
device has been assigned and the PUB device code is then
analyzed. The OPEN bit in the DTF table is then turned on.
c. For console files (DTFCN), no OPEN logic is required.
d. For tape files (DTFMT), the PUB device type code must specify TAPE. If an IOREG is specified (for output tapes only), the
address of the appropriate rOAREI is placed in it. For input
files, there is separate processing for tapes with standard
label, nonstandard label, and no label. For output tapes, both
tape data files and work tape files are treated as no label
tapes. CMS Method of operation and Program Organization 2-141

e. For disk files (DTFxx), the LUB is verified to ensure that the
logical unit bas been assigned. 1 check is made to ensure that
the DOSCB exists for the DTF filename. For disk output files,
the address of the appropriate IOAREl is placed in IOREG. For
disk input files, the existence of the file is verified via a
call to DKSSST. Also, EXTENT information is initialized and
the OPEl bit is posted.
f. DTFDT and DTFCP are separate DTF types that could describe any of the above devices.
4. After all files in the table have been opened, DKSBOP returns
control to the problem program via SVC 11.
5. If errors are encountered during DMSBOP processing, an error
message is issued and return is .ade via SVC 6.
The CftS/DOS routine that processes CLOSE requests is DMSCLS, whose logiC
is analogous to that of DKSBOP, the OPEN routine described above: when CLOSE expands, register 1 points to $BCLOSE and register 0 points to the
list of DTF/ACB addresses. The same table containing DTFs and lCBs used
to open files is also used to close those files. Each entry in the
table is processed as it occurs, with control passing to a VSAM CLOSE routine ($$BCVS1K) when an ICB is encountered. The OPEN bit is then
turned off. PROCESS CMS/DOS EXECUTION-RELATED CONTROL The CMS/DOS FETCH and DOSLKED com.ands simulate the operation of the DOS/VS fetch routines and the DOS/VS Linkage Editor. The three CMS .odules that perform this simulation are: • DKSFET--Prcvide an interface to interpret the DOS FETCH command line
and execute the phase, if START is specified on the command line. • DftSFCH--Bring into storage a specified phase from a system or private
core-image library or from a CMS DOSLIB library. • DMSDLK--Link edit the relocatable output of the CMS/DOS language
translators to create executable programs. The DOS/'S FETCH function is simulated by CMS .odules DMSFET and DMSFCH. The main control block used during a FETCH operation is FCHSECT, which
contains addressing information required for I/O operations.
The FETCH command line invokes module This module first
validates the command line and issues a FILEDEF for the DOSLIB file. It
then issues a FILEDEF for a DOSLIB file. DKSFE7 then issues a DOS SVC 4, which invokes the module DMSFCH to perform the actual FETCH
operation.
2-142 IBM VM/370 Systea Logic and Program Determination--Volume 2