2. USAGE GUIDELINES › 2.3 System Level Migration Considerations
2.3 System Level Migration Considerations
This section contains information about migration
requirements for the VM Data Transfer Program when the level
of VM or CMS changes.
CMS LEVEL CHANGES
The currently supported levels of CMS are:
Level Host VM
-------- --------------------------------------------------
CMS 16 z/VM 3.1.0 z/VM Feature
CMS 17 z/VM 4.1.0 z/VM Feature
CMS 18 z/VM 4.2.0 z/VM Feature
CMS 19 z/VM 4.3.0 z/VM Feature
CMS 20 z/VM 4.4.0 z/VM Feature
CMS 21 z/VM 5.1.0 z/VM Feature
CMS 22 z/VM 5.2.0 z/VM Feature
CMS 23 z/VM 5.3.0 z/VM Feature
Additional levels of CMS will be supported as they are
introduced by IBM.
The following matrix indicates when you should regenerate VMT
due to a change in your system level. We have included
information should you ever need to transition to a lower
release.
+----------+-----------------------------------------------------------------------+
| Upgrading| Upgrading To: |
| From: | CMS 16 CMS 17 CMS 18 CMS 19 CMS 20 CMS 21 CMS 22 CMS 23 |
+----------+-----------------------------------------------------------------------+
| CMS 16 | --- No No No No No No No |
| CMS 17 | No --- No No No No No No |
| CMS 18 | No No --- No No No No No |
| CMS 19 | No No No --- No No No No |
| CMS 20 | No No No No --- No No No |
| CMS 21 | No No No No No --- No No |
| CMS 22 | No No No No No No No No |
| CMS 23 | No No No No No No --- --- |
+----------+-----------------------------------------------------------------------+
If code regeneration is required, do the following:
Step 1. Log on to the VM Data Transfer Program user ID (in
VM).
Step 2. Access the VM Data Transfer Program installed code
minidisk as "A", then enter the command:
L VMTXMIT $EXEC *
If the response is not VMTXMIT $EXEC A, re-access
the installation minidisk using the CMS ACCESS
command.
Step 3. Enter the command:
VMTFIRST
When you are prompted to continue the generation
process, respond Y.
This will rebuild the executable components of the
VM Data Transfer Program at the level required by
the new CMS release.
Step 4. Review the parameters you have set for data
transfer to determine whether or not they are still
appropriate for your new environment.
This completes the regeneration of the CMS portion of the VM
Data Transfer Program.
ACCOUNT DATA
Account data is obtained from CP by means of the CMS RETRIEVE
command. The RETRIEVE command creates a CMS file containing
account records. The name of this file is ACCOUNT $Ammddyy,
where 'mmddyy' is the date on which the file is created
(started). You have two options for presenting this data to
VMT for transmission.
The first option is to modify the data collection process in
the virtual machine that runs the RETRIEVE command so that it
punches the account data to the VMT virtual machine when
collection is halted. This requires the use of the
'alternate account data userid' facility which is activated
via the VMTXMIT PARMS Common Transfer Parameters.
The second option requires changing the account data source
in VMTXMIT PARMS Account parameters to 'FILE', which allows
VMT to read the account data directly from a CMS minidisk.
If you use this option, you must also update the VMTFDEF exec
to LINK and ACCESS the minidisk containing the account data
if this is not done externally, and to issue a FILEDEF for
the data. When this option is used, you will also need to
change the way VMT is notified that data is available. One
means is to AUTOLOG the VMT virtual machine and have VMTXMIT
executed from the PROFILE exec to transmit account data.
Another option is to run VMT disconnected and have VMTWAITR
executed from the PROFILE exec when VMT is AUTOLOGged. (This
now occurs if you are running VMTPROF from the PROFILE exec.)
You can then have the account data collection virtual machine
signal VMT to begin transferring data. Chapter 7 of this
guide contains a complete discussion of the relevant
parameters.
MONITOR DATA
VM monitor data is presented to a collector in virtual memory
only. CP does not write the monitor data to any recording
medium (disk, spool, or tape). A collector is required to
copy the contents of virtual storage to a CMS file for
processing by a post-processor, such as CA MICS.
IBM provides a program called MONWRITE to perform this
function. MONWRITE runs in a collector virtual machine. The
monitor parameters must be set before starting MONWRITE.
Once MONWRITE is started, monitor data generation can be
initiated using the CP MONITOR START command. At some
predetermined time, the MONWRITE program must be stopped so
that its data file can be used by a post-processor. This is
accomplished by using the CP EXTERNAL command of the MONWSTOP
CMS immediate command. (The use of the EXTERNAL command is
simpler in a disconnected virtual machine.) This is a process
that is best automated with a secondary operator facility,
such as the CA AutoMate/VM product. After the MONWRITE
program is stopped, the VM Data Transfer Program must be
started. This can be done either by AUTOLOGging VMT, or
running the VMT virtual machine disconnected and waiting for
a signal (similar to the second account option above).
However you choose to implement MONWRITE, the VM Data
Transfer Program must be set up to process a new data source
by setting the parameters for VM Monitor Transmission.
When you set up the parameters for z/VM monitor data, you
should set the "Data Source" as MONWRITE. The data file
created by MONWRITE contains fixed length, 4096 byte records.
Only specify 'FILE' as the data source if the data has been
preprocessed by VMT into variable length records. You must
ensure that the minidisk containing the Monitor data has been
accessed and linked by the virtual machine running the
CA MICS Data Transfer Program prior to issuing a FILEDEF for
the file in the VMTFDEF exit. You should not place DCB
attributes on the FILEDEF command unless the input file is on
a tape that was created directly by MONWRITE, in which case
the DCB attributes must be specified as RECFM U LRECL 28672.
There are programs from other vendors that can be used to
replace MONWRITE. If you use one of these, the CMS file
created must be in the same format as the one created by
MONWRITE.
Macro Library Restructure
The structure of the macro libraries (MACLIBs) was changed in
CMS Release 5.6. In all prior releases, CMS used two
libraries for macros and copybooks: CMSLIB MACLIB and DMSSP
MACLIB. In CMS Release 5.6 and above, all general
programming interfaces reside in DMSGPI MACLIB, and CMS
internal function macros and copybooks reside in DMSOM
MACLIB.
The CA MICS VM Data Transfer Program requires access to the
appropriate macro libraries, plus access to the OS/MVS
simulation macro library (OSMACRO MACLIB) during the
installation of maintenance. To verify that the CA MICS VM
Data Transfer Program has the access to the macro libraries,
enter the following commands at CMS Release 5.6 and above:
L DMSGPI MACLIB *
L DMSOM MACLIB *
L OSMACRO MACLIB *
If CMS responds with the message "File not found", contact
your VM Systems Programmer for access to the missing macro
libraries.
