Updating CMS To regenerate a nucleus which exists as a disk file (CMSNUC NUCLEUS, for example), issue the following commands:
spool pun to *
punch cmsnuc nucleus a1 (noheader)
ipl OOc You may then answer the IPL messages previously described. This
time, you specify the IPL address as 190 instead of 390, and enter the
correct cylinder for your system disk. Now you can go on to save the CMSSEG and the eMS saved system, if you wish. If a named saved system has been built from this CMS system disk,
it must be resaved because the SSTAT is recreated only when the disk is
loaded (for example 190). Appendix C details what must be regenerated
for changes in any CMS text file. Saving CMSSEG and the CMS System If your system has entries in the system name table (DMKSNTBL) for a CMSSEG discontiguous segment and a named CMS, you should now save these
system names. To do this, first be sure that you have defined virtual
machine storage to a value above the location of CMSSEG and the loader
tables, for example 2M.
Then, you can IPL CMS and issue the CMSXGEN command to save the CHSSEG segment:
ipl 190 parm seg=null
(null line) Y (19E) RIO R;
access 190 b/a
R;
cmsxgen 100000 where 100000 is the hexadecimal address where the segment is loaded.
This number must correspond to the starting page number specified in the NAMESYS macro for the CMSSEG saved system name. CMSXGEND generates a LOAD MAP on OOE which will appear in your reader and is required by IPCS. When the CMSXGEN procedure is completed, you should IPL the CMS system disk again, and issue the CP SAVESYS command immediately, before
pressinq a carriage return to complete the IPL:
ipl 190 savesys cms
In this example, CMS is the name of the saved CMS system. If you have
specified another name for the saved CMS system, you should specify that
name when you issue the SAVESYS command. SAVESYS is a CP privilege
class E command; it allows you to write on the CP system residence
volume. NOw, the saved portion of CMS may be shared among many users, who can
load CMS by referrinq to its saved name, for example
ipl ems
When you IPt a saved CMS system, CMS operates as if an IPL specific device had occurred, with the single exception that
directory for the system disk is part of the nucleus.
356 IBM VM/370 Planning and System Generation Guide
of a
the

Page of GC20-1801-10 As Updated April 1, 1981 by TNL GN25-0837
Updating CMS Update Procedures for CMS/VSAM and Access
Method Services You are responsible for ordering and applying all updates to DOS/VS that
affect the VSAM and access method services routines and the DOS logical
transients ($$BOMSG1, $$BOMSG2, $$BOMSG7, and $$BENDQ) that CMS distributes. You can order these updates in card form or on tape.
If you order the updates on cards, you must remove all of the DOS/VS job control statements from each PTF (program temporary fix) deck and
place a CP ID at the beginning of the deck. The CP ID card must
contain the userid of the CMS virtual machine that is being used to
update and access method services.
For example, if you vant to apply an update to a module using the
MAINT virtual machine, your ID card is:
ID MAI}1T If you installed VSAM and access method services under eMS as an OS user, VSAMGEN created eMS text files for all the required DOS/VS relocatable library modules. Now you need not have a DOS/VS relocatable
library for updating. CMS creates text files from the updates and
replaces the old text files on your A-disk with the new text files.
Text files must have a filetype of TEXTe For example, after you have
updated an object module using VMFASM, the most recent object file has a
filetype such as TXTLOCAL. To use that text file here, you must rename
it to a filetype of TEXT. If there is currently a text file on the systeID disk, you may want to rename it too, so that your updated text
file (which may reside on another disk) is the one that is loaded. VSAMGEN UPDATE CONSIDERATIONS Applying DOS/VS PTFs to either the CMSVSAM or the CMSAMS discontiguous
saved segments may result in the generated segment exceeding the space
defined for it in the system name table (see the NAMESYS macro of the DMKSNT module). You may want to anticipate this problem by defining in
the system name table an additional shared and nonshared segment for
each of the discontiquous saved seqments (CMSVSAM and CMSAMS). This is
one way of providinq for additional Alternatively, upon completion of the VSAMGEN update procedure, you
can check whether the updated segments have exceeded their definitions
and correct that situation as follows:
1. Determine the new size of the changed VSAM and/or access method
services shared and nonshared segments by subtracting the phase LOCORE address from the BICORE address indicated on the linkage
editor map. The phase names are:
2. • Dr-:[ SVVS - VSAM shared • Dl'lSVV}1 - VSAM nonshared • DMSVAS - access method services shared • DMSVAN - access method services non shared • DMSV33 - VSAM shared (DOS/VS Release 33 or 34)
Compare the new sizes of these segments with the sizes of
correspondinq shared or nonshared segments as defined in DMKSNT NAMESYS macro.
the
your Part 5. Updating VM/370 357