I DOS VSAM Program CMSDOS DCSS DOS Transient
Area I OPEN ACB1 __ rl $$BOVSAM __ I I ----J I $$BCVSAM CLOSE ACB1
B-disk
for OS or DOS User $$BACLOS Figure 20. The Relationships in Storage between the User Program and
the CMSDOS and CMSVSAM DCSSs CMSVSAM ncss. DMSBOP then
issues a DOS OPEN via SVC 2
into the DOS transient area.
initializes the transient work area and
to bring the VSAM OPEN $$BOVSAM transient When VSAM processing completes, control returns to the user program directly. DMSCLS processing is nearly the same as processing for DMSBOP. When DMSCLS is entered, it checks for an ACB to process. If there is one,
the $$BCVSAM transient work area is initialized and SVC 2 is issued to
FETCH the VSAM CLOSE transient $$BCVSAM into the DOS transient area. When the VSAM CLOSE routines complete processing, control returns to the
user program, as in the case of OPEN. When DMSXCP processes an EXCP request, it determines if the request is
from IKQLAB (that is, to read the SYSRES label information). If so, the
label information area record is filled in from the appropriate DOSCE. (DMSXCP determines that the caller is IKQLAB by co.paring the address of
the caller with the address stored in NUCOI by DMSDOS, as described
above. ) CMS Method of Operation and Program Organization 2-117

Executing a VSAM Function for an OS User
as user requests for services are handled by DOS/VS code that
resides in the DCSS. To access this code, as VSAM requests are
intercepted by the module DMSVIP, the interface between the as VSAM requests and the CMS/DOS and DOS/VS VSAM routines.
Because DMSVIP is in the CMSVSAM segment, it is available only when
that segment is loaded. Module DMSVIB, which resides in the CMS nucleus, is a bootstrap routine to load the CMSVSAM segment and pass
control to DMSVIP. DMSVIP receives control fro. VSAM request macros in three ways: via SVC (e.g. OPEN and CLOSE), via a direct branch using the address of DMSVIP in the ACB, and via a direct branch to the location of DMSVIP whose address is 256 bytes into the CMSCVT (CMSCVT is a CMS control
block that simulates the as CVT control block) • This last technique is used by the code generated fro. the as VSAM control block 1I<=lnip111<=ltion SHOVCE
i TFSTCE. Tnat is, the address at 256 into CVT is assumed to be that of a control block
that is at displacement 1'12' has the address of the VSAM control block
manipulation routine. To ensure that DMSVIP receives control fro. these
requests, the address of DMSVIP is stored at 256 bytes into CMSCVT. However, until the segment is loaded, the address at CMSCVT+256 is the address of module DMSVIB rather than the address of DMSVIP. The
address of DMSVIP replaces that of DeSVIB when CMSVSAM is loaded. Both DMSiIB and DMSVIP have pointers to themselves at 12 'bytes into themselves to ensure that this technique works.
Figure 21 shows the relationships in storage between
program, the os simulation and interface routines, and the CMSVSAM DCSSs. the user CMSDOS and OS VSAM Program OPEN ACBl CLOSE ACBl Figure 21. CMS Module oMSSOP DMSVIP oMSSOP19 oOSOPEN BALR 14,15 DMSSOP20 DOSCLOSE BALR 14,15 Relationship in
Simulation and CMSVSAM DCSSs DOS Transient CMSDOS DCSS DMSDOS DMSBOP DMSCLS Storage between the User Interface Routines, and
B-disk
for OS or DOS User Program, the
the CMSDOS CS and
The following description illustrates the overall logic of that
control flow.
2-118 IBM System Logic and Program Determination--Volume 2