DMSFCH first determines .here the phase to be fetched resides. The
search order is private core-image library, DOSLIB, system core-image
library. If the 'phase is not found in any of these libraries, DHSFCH assumes that the FETCH is for a phase in a system or private core-image
library. To find a DOSLIB library member, OS OPEN ano FIND macros are
issued (SVC 19 and 18). When the member is found, OS READ and CHECK macros are issued to read
the first record of the file (the member directory). This record
contains the number of text blocks and the length of the member.
All addressing information is stored in FCHSECT and the text blocks
that the phase are read into stcrage. If the read is from a CMS disk,
issue the OS READ and CHECK macros to read the data. If the read is
from a DOS disk, first determine whether this is the first read for the DOS discontiguous shared segment (DCSS) _ If this is the case, CCi information is relocated to ensure that the DCSS code is reentrant. For
all reads for a DOS disk, a CP READ DIAG instruction is issued. When the entire file is read, it is relocated (if it is relocatable).
If a DOSLIB is open, close it using an OS SVC 20 and return control
to DMSFET. DMSFET then checks to see whether START is specified and, if
so, an SVC 202 is issued for the CMS START command to execute the loaded
file. When all FETCH processing is complete, control returns to the command handler, DKSITS. CMS simulation of the DOS/VS Linkage Editor function directly parallels
the DOS/VS implementation of that function. For detailed information on
the logic of the function, see the publication Order Ne. SY33-8556. Note that the modules comprising the DOS/VS Linkage Editor are
prefixed by the letters IJB and are separate CSECTs. ALL of these CSECTs have counterparts contained within the ene eMS module, DMSDLK. They are treated as subroutines within that module, but perform the same
functions as their independent DOS/VS counterparts and have been named using the same naming conventions as for the DOS/VS CSECTs. For example, the IJBESD CSECT in DOS/VS is paralleled by the CMS DMSDLK subroutine DLKESD. A brief dscription of the logic follows. The CMS/DOS DOSLKED command invokes the module DMSDLK, which is entered at subroutine DLKINL.
DLKINL performs initialization and is later overlaid by the text buffer
and the linkage editor tables. DLKINL starts to read from a DOSLNK file
and processes ACTION statements, if there are any_ On encountering the first non-ACTION card (or if there is no DOSLNK file), the main flow is entered. Depending on the input on the DOSLBK or the TEXT file, records from either of those files may be read or
records from a relocatable library may be read. The type of card i.age
read determines the subroutine to which control is given for further
processing.
An ENTRY card indicates the end of the input to the linkage editor.
At this point, a map is produced by subroutine DLKMAP. DLKRLD is then
entered to finish the editing of object .odules by relocating the
address constants. If the phases are to be relocatable, relocation
information is added to the output on the DOSLIB. Updating of the DOSLIB library is performed by DLKCAT using the OS STOW macro. CMS Method of operation and Program Organization 2-143
A significant deviation from DOS/VS code is the use of OS macros, in S08e instances, rather than DOS/VS macros. To take advantage of CflS support of partitioned data sets, the OS OPEN, FIND, READ, CHECK, and CLOSE macros are issued rather then their DOS/VS counterparts. SIMULATE DOS SVC FUNCTIONS All SVC functions supported for CMSjDOS are handled by the CMS module DMSDOS. DMSDOS receives control from DMSITS (the CMS SVC handler) when
that routine intercepts a DOS SVC code and finds that the Dossve flag in DOSFLAGS is set in NUCON. DMSDOS acquires the specified SVC code from the OLDPSW field of the
current SVC save area. Using this code, DMSDOS computes the address of
the routine where the SVC is to be handled. Many CMS/DOS routines (including DMSDOS) are contained in a
discontiguous shared segment (DCSS) e Most SVC cedes are executed within DMSDOS, but some are in separate modules external to DMSDOS. If tpe SVC code requested is external to DMSDOS, its address is computed using a
table called DCSSTAB; if the code requested is executed within DMSDOS, the table SVCTAB is used to the address of the code to handle
the SVC. The items below show the SVCs supported by CMS/DeS simulation
routines, the name of the macro that invokes a SVC code, the .odule that executes the code, and a brief statement describing how the SVC function is performed. Q: EICf -- Handled by .odule DMSICP ••• reads from CftS or DOS/VS formatted disks. CCis are converted to appropriate CflS I/O requests,
for example, RDBUF/WRBUF, C!RDRD/CARDPH. The ceE is posted (indicating I/O completion) using CMS return infor.ation. If a non-zero return code
is returned, a CANCEL is performed. I/O requests to DOS disks are
handled using CP DIAGNOSE instructions. SVC 1: -- Handled by DMSFCH ••• loads a problem program phase into
core and executes it, if execution is requested. For details on how FETCH works, see the section "Bring a Phase into Storage fer Execution: DMSFET and DMSFCH." SVC 2: FETCH -- Handled by DMSFCH ••• loads a $$$$B-Transient phase into core-and--executes it, if execution is requested. For details on how FETCH works, see the section "Bring a Phase into Storage for Execution: DMSF.T and DftSFCH." !: -- Handled by DMSFCH ••• loads a problem program phase into
user storage and executes it, if execution is requested. Fer details en
how FETCH works, see the section "Bring a Phase into Storage fer
Execution: DMSFET and DMSFCH." SVC 5: -- Handled by DMSDOS ••• provides the user with a way of altering bytes 12 through 23 of the partition communication region (BGCOM). Checks to ensure that the specified field is correct length
and then moves the information to the specified field. SVC 6: CANCL Handled by DMSDOS ••• cancels a CMS/DOS sessione Processing-depends on value in register 15 on entry; if above 256 the
request is from a system program. If below 256, request is from a user
program. processing continues with control passing to EOJ code,
described below.
2-144 IBM VM/310 System Logic and program Determination--Volume 2
Previous Page Next Page