Installation Verification Procedure
To execute the IVP with virtual machines other than IVP1 and IVP2: Enter, in place of the command IVP 1: IVP 1 userid1 Enter, in place of the command IVP 2: IVP 2 userid2
where useridl and userid2 identify the two virtual machines in which the
EXEC procedures IVP 1 and IVP 2 (respectively) are to be executed.
To execute the IVP in a single virtual machine, enter the command
(from any logged-on virtual machine): IVP *
This causes the IVP tests to be run in that single virtual machine.
Intermachine transfer of data is simulated by transferring virtual
punched output to the same virtual machine's virtual card reader.
Interpreting the Test Results Messages at the end of the IVP test indicate successful completion. If
any errors are detected by the IVP, call IBM for software support,
because an error usually indicates a serious malfunction of the
generated system. The IVP procedure identifies each command being tested
just before the command is executed.
Error messages are displayed in a four-line format, for example:
*** IVP FAILURE HAS OCCURRED ***
*** COMMAND: STATE IVPTST *
*** EXPECTED RETURN CODE 28
*** RECEIVED RETURN CODE 0 These messages indicate that the CMS STATE command had a return code of 0, instead of the expected 28.
All information messages that originate within the IVP are preceded
by three asterisks (***).
If any command fails, the IVP procedure terminates. Follow the
instructions (if any are given) to log off the virtual machine. Once the IVP procedure has executed successfully, continue the system
generation process by loading and saving discontiguous saved segments,
as described in the section that follows.
266 IBM VM/370 Planning and System Generation Guide
Loading and Saving Discontiguous Saved Segments Loading and Saving Discontiguous Saved
Segments
After you have finished generating and testing your new system, you may
wish to load and save discontiguous saved segments. The DMKSNT module
supplied with the starter system includes entries for saved segments
called CMS, CMSSEG, CMSVSAM, CMSAMS, CMSDOS, and INSTVSAM. You may also create_ your own entries. See the section "Preparing the System Name
Table File in Part 2.
Throughout the following discussion, it will be helpful for you to
refer to Figure 31, which shows how the CMS discontiguous saved segments
are loaded in virtual storage if you use the DMKSNT module supplied with
the starter system.
Before a discontiguous saved segment can be attached and detached by
name, it must be loaded and saved. The discontiguous saved segment must
be loaded at an address that is beyond the highest address of any
virtual machine that will attach it. It is the system programmer's
responsibility to make sure the saved segment is loaded at an address
that does not overlay the defined virtual machine or any other saved
segment that may be attached at t-he same time. The load addresses are
determined by the entries you coded in your DMKSNT module.
The load address for the discontiguous saved segment should be just
beyond the largest virtual machine that uses it. If the load address is
unnecessarily high, real storage is wasted because CP must have segment
table entries for storage that is never used.
For example, assume you have five CMS virtual machines in your
installation. Also assume that all five use the CMS support for DOS program development and testing which is in a 32K segment named CMSDOS. If each of your five CMS virtual machines has a machine size of 320K, you should load the CMSDOS segment just beyond 320K but below 992K (so
as to contain it within 1M). Otherwise real storage would be wasted
because CP must maintain segment table entries for each 1024K of
storage. Once the named segment is loaded at the correct address, you can save
it by issuing the CP SAVESYS command. To be sure that a discontiguous
saved segment has storage protection, set the storage key for the
segment accordingly. CMS has a new command, SETKEY, to do this. The CMS SET KEY command is described in the 1M/310 Guide. CMS has EXEC procedures that help you load, set storage keys for, and
save the CMS discontiguous saved segments. The DOSGEN EXEC procedure
loads and saves DOS segments. The VSAMGEN EXEC procedure loads and
saves the CMS/VSAM and Access Method Services segments. The CMSXGEN EXEC procedure loads and saves CMSSEG, which contains the CMS Editor, EXEC processor, and OS simulation routines. You used the CMSXGEN EXEC procedure to save CMSSEG in Step 24 of the system generation procedure.
The DOSGEN and VMSAMGEN EXEC procedures are described later in this
section.
Note: These procedures for loading and saving discontiguous saved
segments and the associated text files are 'mode l' to reduce the amount
of storage needed for the master file directory in the user's virtual
machine. The system disk must be accessed (any mode, A through G)
before loading any discontiguous saved segment. Make sure that this is
done any intermediate IPL of CMS. Part 3. Generating VM/310 (CP, CMS, RSCS, and IPCS) 261
Previous Page Next Page