respectively. None, some, or all of the
updates may exist to be applied.
Record 5 defines an auxiliary file that
specifies an auxiliary list of PTFs or
updates that are to be applied. Record 5
defines an auxiliary file identified as
'filename AUXxxxxx', where 'filename' is
the same as the filename of the input file
and xxxxx is an update identifier (the
update identifier for an auxiliary control
file cannot be "aux"). Records in the
auxiliary file have the following format
for PTFs to be applied: PTF A30246CA A21726CA PTF 107426Cl * Any comment The PTF field is an optional identifier,
and the second field (for example, A30246CA) defines a specific PTF to be
applied. The PTF has a 'filename A30246Cl' identification, where 'filename' is the same as the filename of the file to be
updated. The filetype of a format Axxxx6Cl is used to indicate an APAR answer or PTF for APAR number xxxx. The comment field is
used to describe the function of the
particular PTF. The * record is ignored
and is used to provide additional comments on any updates or PTFs. The updates (PTFs included) are applied
in the reverse order in which they appear.
In the previous example, the updates would
be applied in the following order: A07426CA A21116CI A30246CI UPDTup3 UPDTup2 UPDTup1 The PTF records can be directly included
in the CNTRL file if desired, but it is
usually more convenient to place them in a
separate auxiliary (AUXXXxxx) file.
There can be any number of UPDTxxxx definition and auxiliary control file
definition records, but only one BACS record. The complete CNTRL file can have any filename, but typically has the same name as the first specified UPDTxxxx control record. In the example. the file
could be named UP1 CNTRL. The underlined fields in each record mark the level identification fields. The
highest level (last) update to be applied
selects the name that can be used to
identify updated files. In the example, if UPDTup3 was the last update applied, then
the name selected would be naa03e The
value for the identification usually
consists of a combination of the update
identifier uP'. up2, (uP to four
characters) and additional characters up to
a maximum of 5 for the combined update
identifier and additional characters. If no
updates are applied, then the namOO field
is selected to identify the TXTnamOO produced. This name can be used to
uniquely identify updated files. The text
files described above, for instance, can
have a filetype of TXTup3. It is
desirable, on occasion, to have entries in
the user CNTRL file that specify a level
identification but no update. A record of
the following format. for example. is
allowed:
This is because the control file serves a
double purpose and is used for loading text
decks as well as updating input files. An
identifier of TEXT as a name causes special
handling in the VBFASe EXEC procedure.
whether or not an update is used with it.
A name of iEXT is used without level
identification catenation. Thus, TEXT becomes the filetype. SYSTEM EXEC PROCEDURES Several system control files provide for system update and creaticn. Some EXEC procedures invoke others cr make use of
user-supplied control files to accomplish
various functions such as multilevel
updating, text generation, and macro library generation.
The VMFASft procedure performs the
multilevel update function by invoking the DftSUPD module (via the CBS UFDITE command) before assembling the desired files. To update and assemble a source file. the VMFASft procedure is invoked in the
following way: VBFASft filename control [options]
where 'filename' is the name of the ASS'lftBLE file to be processed and 'control'
is the naae of the user CNTRL file that
contains the BICS (macro library), update,
and any lUXxxxx control records. The VMFASM procedure invokes the DftSUPD module via the CMS UPDATE co.mand, passing the
values 'filename', 'ASSEMBLE', and
'control'.
126 IBM V"/370 Service Routines program Logic

The UPDATE comaand returns a level
identifier and a MAC LIB list froa the 8ACS record of the control file. If the
identifier is TEXT, then that becomes the
filetype of the complete text deck;
otherwise the filetype is TXTxxxxx (for example, TXTup3m1). The EXEC procedure
then reads the MACLIB list passed by UPDATE and issues a GLOBAL command to prepare for
the assembly using the specified libraries.
The ASSEMBLE program is invoked with the
specified options. If no options are
specified for the ASSEMBLE command, the
defaults are: PRINT, NOTERM, LIST, NODECK, NORENT, SYSPARM(), and XREF(FULL). The options that can be specified for the VMFASM EXEC are: DISK, NOTERM, NOLIST, DECK, RENT, EXP, XREF, and RLD. The
defaults for the VMFASM EXEC are: PRINT, TERM, LIST, NODECK, NORENT, SYSPARM(SUP), XREF(SHORT), and NORLD. The VMFDATE program is used to construct
a record for each MACLIB used and for the ASSEMBLE file. Each record is placed in
the auxiliary file 'filename UPDATES'. The
text deck produced by the assembler is combined with the file produced by the VMFDATE program and is named 'filename TXTxxxxx', where 'filename' is that of the ASSEMBLE file, and 'TXTxxxxx' is
constructed from the update level
identifier returned by the UPDATE co.mand.
All intermediate files are erased, leaving
only the original ASSEMBLE and UPDTxxxx files, and the newly created text file. Procedure ------ The GENERATE procedure is generally used
during system generation. It can build a CP, CMS, or RSCS nucleus and punch or
create self-loading card decks for the four
standalone service programs (DMKDIR, DMKDDR, DMKFMT, and IBCDASDI). GENERATE
can also build a new VM/370 directory, a
new real I/O deck (DMKRIO), a new buffer
load (DMKFCB), a new system name table (DMKSNT), or a new system deck (DMKSYS). GENERATE can also load the IPCS modules from tape onto the IPCS A-disk. The
GENERATE procedure uses the V8FASM EXEC procedure to reassemble DMKRIO, DMKFCB, DMKSNT, and DMKSYS. It also uses the VMFLOAD program to build the CP, CMS, or
RSCS nucleus. VMFLOAD SERVICE PROGRAM The VMFLOAD program uses two user-supplied
procedures, a loadlist EXEC and a 'control'
file identical in foraat to the CNTRL file
used by V8FIS! and UPDATE, to produce a
punched deck comprised of several text files: The V!FLOAD progra. is invoked as a C8S command in the following way: V!FLOAD loadlist control
The loadlist is a user-supplied EXEC file consisting of several records of the
following format: &CONTROL OFF &1 &2 &3 filename [filetype]
&2 &2 &3 filename [filetype] The 'filename' specifies the name cfa
text file to be punched. The text files
are punched in the order specified. If a
filetype is specified, a search is made for
that specific file, and if it is found it
is punched without a header card, and "the
search then bypasses the contrel file.
If the filetype is not given, the
specified control file is used to search
for the highest level text file available,
and it is punched.
The VMFLOAD program displays a
confirmation or error message uFon completion. Before invoking the loadlist
procedure, a SPOOL PCB CCNT command line is
executed to assure that the punched files
appear as one deck. The command lines SPOOL PCE NOCONT and CLOSE PCB are executed uFon completion.
The control field is used only if the
filetype is not specified. The centrel
field specifies a user-suPFlied centrel
file with a filename of 'control' and a
filetype of CNTRL. This control file is of
the same type and format as the one used to
perform multilevel updates. Indeed, mest
often the file used to Iroduce the updated
and assemtled text decks is the one used to
load the text decks. V!FLOAt uses the control file to search
for the desired text deck in the order in
which the identifiers are specified in the
file. The first file lecated is punched,
and all lower files are igncred. If the
end is reached without finding a text file, VMFLOAD displays the message 'filename TEXT' NOT FOUND, and continues processing
with the next entry in the loadlist EXEC. It is quite possitle te have a comFleted load deck coaprised of different levels of
text decks. Chapter 7. Procedures for Generating and Updating VM/370 127