8. INSTALLATION AND MAINTENANCE › 8.4 Packaging

8.4 Packaging

This section describes product change packaging for VMT.  It
is intended for use in building a product change for delivery
to clients and discusses the additional requirements for
packaging VMT beyond the requirements for PSP Online.

MAINTENANCE INSTALLATION OVERVIEW

The maintenance for VMT is installed into the CA MICS complex
libraries using PSP Online.  Following the installation into
the complex, the updated source modules are copied to VM
using the VMTXRDR job.  In VM, the maintenance is loaded by
the VMTMNT EXEC, and the executable code is regenerated.

PSP ONLINE

The delivery package for VMT consists of the standard
components required by PSP Online.  The installation of
maintenance items for VMT must follow the standard PSP Online
form and procedure.  If multiple VMT product changes are
selected at the same time, they will be installed in the
CA MICS complex libraries correctly, however each change must
be delivered to VM separately and each set of product change
instructions must be followed to completion.

MAINTENANCE PACKAGE REQUIREMENTS

The maintenance package for VMT consists of updates to source
members, new and/or replacement members.  The package also
includes two members that govern how the maintenance is
copied to VM.  These members reside in (are delivered to)
sharedprefix.MICS.HOLD.PARMS, and are named VMTnnnnI and
VMTnnnnG, where 'VMTnnnn' is the product change number.

o  VMTnnnnI - Items included for copy to VM

The VMTnnnnI member is new with each product change.  It
contains a list of all members that are to be copied to VM,
the originating library for each member, and the CMS filetype
to be assigned in CMS.  VMT0000I is a special version of the
copy member that contains a reference to all files that are
ever shipped to CMS.  This copy member is used to install VMT
as a new product (or to reinstall or refresh the product) in
CMS.  If new modules are created for residency in CMS, they
MUST be added to VMT0000I, and the updates to VMT0000I
delivered to all VMT customers.

    o  VMTnnnnG - Items to generate in VM

       The VMTnnnnG member is new with each product
       change.  It contains a list of items to be regenerated
       in CMS.  It also contains a special control file that
       provides information for use by VMTMNT.  Any special,
       one-time-use files may also be appended to this
       member.

    o  VMT0000G - Generate all modules in CMS

       This member is a special version of the generation
       list.  It causes all items listed in VMTGENS GENLIST
       to be rebuilt.  It does not normally require any
       updates.

VMTnnnnI/G Format and Contents

The following is an example of an installation delivery file
in sharedprefix.MICS.HOLD.PARMS(VMT0012I):

(1)     %VMTRDR(DD=HPARMS,FT=FIXINFO,MEMS=VMT0012G)
(2)     %VMTRDR(DD=ASM,FT=ASSEMBLE,MEMS=VMTXFR VMTPUN)
        %VMTRDR(DD=CLIST,FT=$EXEC,MEMS=VMTXMIT)
        %VMTRDR(DD=CLIST,FT=$MAIHLP,MEMS=VMTH0116)
        %VMTRDR(DD=SOURCE,FT=$GENLIST,MEMS=VMTGENS)

The following sample illustrates the contents of a generation
control file in sharedprefix.MICS.HOLD.PARMS(VMT0012G):

(3)     * comment line
(4)     MSG Installing VMT0012
(5)     RUN (0) RENAME VMTRDR AUXWRK * = AUXFIX =
(6)     GEN VMTGENU(VMTGENS)
        GEN VMTGENS(VMTXFR)
        GEN VMTGENS(VMTPUN)
        GEN VMTGENS(VMTXMIT)
(7)     HLP VMTH0116
        MSG Installation complete
(8)     :READ TEMP FIXINFO A
        FIXINFO VMT0012G VMT0012 PSP9003
        P(VMT0011 VMT0010)
        S(VMT0009)
        N(VMT0013)
(9)     :READ VMTRDR VMT0012 A5
        ./ * just to show this can be done
        :READ VMTRDR AUXWRK A5
        VMT0012 - deliver change in UPDATE format

Commentary:

(1) This line of VMT0012I copies the generation control file
    to VM.
(2) The remainder of the statements copy updated source
    members to VM.
(3) This demonstrates a comment line in the generation
    control file.
(4) This statement allows informational message text to be
    displayed at the console during product component
    generation.
(5) The RUN statement allows any command to be executed.  The
    numbers in parentheses are the set of permissible return
    codes for successful completion.  For example, RUN (0 28)
    XXX will allow a zero or twenty-eight return code to
    indicate success from command XXX.
(6) The GEN statement specifies the generation list item to
    be invoked.  In this case the generation list is VMTGENU
    and the item is VMTGENS.  On the following line the
    generation list is VMTGENS and the item is VMTXFR.
(7) The HLP statement is used to invoke the VMTHLP HELP file
    generation exec for a single help file.
(8) This :READ statement starts the TEMP FIXINFO file.  This
    must be included in the package.  See below for details
    on TEMP FIXINFO.
(9) This :READ statement starts the special files section of
    the generation control file.  Each :READ statement will
    cause a new file to be created in CMS.  This example
    shows how to deliver a change in UPDATE format.

TEMP FIXINFO - VMTMNT Control Data

The TEMP FIXINFO file is used by VMTMNT to determine how to
proceed after the maintenance package has been loaded to disk
using the VMTMNT RDR command.  The first record of this file
must start FIXINFO followed by the filename of the generation
control file, the product change number and the delivery type
(normally PSPxxxx or BYPASS).  Subsequent records contain
prerequisite, supersedes, and 'not-req' lists.  If any list
is omitted, the list is assumed to be inactive (e.g., no
prerequisite).  The prerequisite list is identified as
P(item1 ...  itemn), the supersedes list is identified as
S(item1 ...  itemn), and the not-req list is identified as
N(item1 ...  itemn).  The not-req list will inhibit
application of the product change if any item in the list is
determined to already have been applied.