2. USAGE GUIDELINES › 2.4 MVS Data Management Considerations
2.4 MVS Data Management Considerations
This section identifies some of the considerations for
retaining transferred data in MVS.
Data Management In MVS
The data received in MVS from VM is required for processing
by the CA MICS VM and CMS Analyzer's Daily data base update.
The complexity of data management is determined by the number
of times data is transferred for a particular data source.
Data can be stored either on disk or tape. The data sets can
be generation data groups (GDGs) or expanded with each
transfer. The combination of these options depends on the
amount of data that is stored in preparation for the daily
update and the availability of disk or tape for storage.
The flow of data from VM to MVS for the CA MICS daily update
is:
1. Data is written to disk (or spool in VM) by the data
collector.
2. Data is moved to MVS by VMT.
3. Data is processed by the CA MICS DAILY update.
4. Data (input to DAILY) is archived for future use.
For a data source, such as VM accounting data, that requires
a small amount of disk space for storage, a combination of
disk storage and the use of a single data set that is
expanded with each data transfer (DISP=MOD) is a good choice
because it provides the simplest data management option. For
a data source, such as VM monitor data, which is voluminous
and may require several data transfers a day to properly
manage the load on the NJE network, the use of generation
data groups and tape may be the best choice.
VM Accounting Data Example:
Transfer JCL:
+-----------------------------------------------------------+
|//...... |
|//RECEIVE EXEC PGM=VMTRCV |
|//PRINT DD SYSOUT=*,DCB=LRECL=133 |
|//OUTPUT DD DISP=(MOD,CATLG,CATLG),UNIT=SYSDA, |
|// SPACE=(TRK,(15,15),RLSE), |
|// DCB=(LRECL=80,BLKSIZE=6160,RECFM=FB), |
|// DSN=prefix.MICS.VM.ACCOUNT.DATA |
|//...... |
+-----------------------------------------------------------+
In this example, the VM Data Transfer Program receives the
accounting data into the data set referenced by the //OUTPUT
dd statement. (Note: this JCL is created in CMS and is
accessible from the VMTXMIT parameters setting function for
Account data.) If the data set referenced by the //OUTPUT dd
statement exists, it is expanded to include the new data;
otherwise it will be created.
DAY080 JCL:
+-----------------------------------------------------------+
|//...... |
|//DAY080 EXEC MICSDBx,SYSPARM= |
|//WORK.... work files generated by VMCPGEN |
|//WORK.... based on VMCOPS |
|//SYSIN DD DSN=sharedprefix.MICS.INCLLIB(DAY080) |
|//* ------ statements from INPUTVMC |
|//ACCOUNT DD DSN=prefix.MICS.VM.ACCOUNT.DATA, |
|// DISP=(OLD,PASS) |
|//* ------ statements added to PROTOLIB(DAY080) |
|//ARCHIVE EXEC PGM=IEBGENER,COND=(0,NE,DAY080.MICS) |
|//SYSPRINT DD SYSOUT=* |
|//SYSIN DD DUMMY |
|//SYSUT1 DD DSN=prefix.MICS.VM.ACCOUNT.DATA, |
|// DISP=(OLD,PASS) |
|//SYSUT2 DD DSN=prefix.ARCHIVE.ACCOUNT.DATA(+1), |
|// DCB=(SYS1.MODEL,...more DCB info...), |
|// UNIT=CART,DISP=(NEW,CATLG,DELETE), |
|// LABEL=(1,SL,RETPD=??????) |
|//* |
|//DELETE EXEC PGM=IEFBR14, |
|// COND=((0,NE,DAY080.MICS),(0,NE,ARCHIVE)) |
|//DATA DD DISP=(OLD,DELETE), |
|// DSN=prefix.MICS.VM.ACCOUNT.DATA |
|//* |
|//...... |
+-----------------------------------------------------------+
The DAILY update JCL for the VM and CMS Analyzer (which is
step DAY080) is found in prefix.MICS.CNTL, member DAILY, on
the MVS system on which CA MICS is installed. It is built
from a shell in sharedprefix.MICS.PROTOLIB. This JCL (DAILY)
is recreated by running a JCLGEN. The account data is
accessed by the CA MICS VM and CMS Analyzer through the
//ACCOUNT dd statement (the name is arbitrary, declared in
VMCOPS, and coded in prefix.MICS.PARMS(INPUTVMC)). The
disposition is OLD on the DAY080 step and subsequent steps to
prevent expansion while the DAILY job is in progress. The
next step (ARCHIVE) copies the raw input data to a tape GDG
for historical retention only after DAY080 has completed
successfully. The DELETE step only executes if both DAY080
and ARCHIVE have completed successfully. If the ARCHIVE or
DELETE steps do not execute, the raw data will not be deleted
and further data transfers will expand the data set.
Standard CA MICS processing will address any case in which
the raw input data is processed more than once by DAY080,
preventing duplicate data in the data base.
VM Monitor Data Example:
Transfer JCL:
+-----------------------------------------------------------+
|//...... |
|//RECEIVE EXEC PGM=VMTRCV |
|//PRINT DD SYSOUT=*,DCB=LRECL=133 |
|//OUTPUT DD DISP=(NEW,CATLG,DELETE),UNIT=CART, |
|// LABEL=(1,SL,RETPD=7), |
|// DCB=(LRECL=8192,BLKSIZE=23440,RECFM=VB), |
|// DSN=prefix.MICS.VM.MONITOR.DATA(+1) |
|//...... |
+-----------------------------------------------------------+
In this example, the VM Data Transfer Program receives the
monitor data into the data set referenced by the //OUTPUT dd
statement. (Note: This JCL is created in CMS and is
accessible from the VMTXMIT parameter setting function for VM
Monitor data.) A new generation of the GDG is created every
time this job runs.
DAY080 JCL:
+-----------------------------------------------------------+
|//...... |
|//DAY080 EXEC MICSDBx,SYSPARM= |
|//WORK.... work files generated by VMCPGEN |
|//WORK.... based on VMCOPS |
|//SYSIN DD DSN=sharedprefix.MICS.INCLLIB(DAY080) |
|//* ------ statements from INPUTVMC |
|//MONITOR DD DSN=prefix.MICS.VM.MONITOR.DATA, |
|// DISP=(OLD,PASS) |
|//* ------ statements added to PROTOLIB(DAY080) |
|//ARCHIVE EXEC PGM=IEBGENER,COND=(0,NE,DAY080.MICS) |
|//SYSPRINT DD SYSOUT=* |
|//SYSIN DD DUMMY |
|//SYSUT1 DD DSN=prefix.MICS.VM.MONITOR.DATA, |
|// DISP=(OLD,PASS) |
|//SYSUT2 DD DSN=prefix.ARCHIVE.MONITOR.DATA(+1), |
|// DCB=(SYS1.MODEL,...more DCB info...), |
|// UNIT=CART,DISP=(NEW,CATLG,DELETE), |
|// LABEL=(1,SL,RETPD=??????) |
|//* |
|//DELETE EXEC PGM=IEFBR14, |
|// COND=((0,NE,DAY080.MICS),(0,NE,ARCHIVE)) |
|//DATA DD DISP=(OLD,DELETE), |
|// DSN=prefix.MICS.VM.MONITOR.DATA |
|//* |
|//...... |
+-----------------------------------------------------------+
The DAILY update JCL for the VM and CMS Analyzer (which is
step DAY080) is found in prefix.MICS.CNTL, member DAILY, on
the MVS system on which CA MICS is installed. It is built
from a shell in sharedprefix.MICS.PROTOLIB. This JCL (DAILY)
is recreated by running a JCLGEN. The monitor data is
accessed by the CA MICS VM and CMS Analyzer through the
//MONITOR dd statement (the name is arbitrary, declared in
VMCOPS, and coded in prefix.MICS.PARMS(INPUTVMC)). The
disposition is OLD on the DAY080 step and subsequent steps to
prevent additional generations from being created while the
DAILY job is in progress. This prevents data from being
archived without being added to the data base. The next step
(ARCHIVE) copies the raw input data to a tape GDG for
historical retention only after DAY080 has completed
successfully. The DELETE step only executes if both DAY080
and ARCHIVE have completed successfully. If the ARCHIVE or
DELETE steps do not execute, the raw data will not be deleted
and further data transfers will add generations to the GDG.
Standard CA MICS processing will address any case in which
the raw input data is processed more than once by DAY080,
preventing duplicate data in the data base.
Note that the input sequence to the DAY080 step is in reverse
order (last in, first out) if the monitor data is in GDG
format but the generation is not explicitly specified within
the data set name. Each GDG data set itself should be
self-contained--that is, it should contain monitor data
collected between the time that the MONWRITE program started
and ended.
Each GDG data set should contain a set of configuration
records (domain 1) at the beginning of the file because each
time an application program (such as MONWRITE) connects to CP
Monitor, Monitor will generate a set of configuration records
first before it generates sample records (this is an IBM
standard).
Multiple self-contained monitor data sets can be processed in
any order. However, if the configuration records are not at
the beginning of the file, you must ensure that the monitor
data sets to be processed by the CA MICS VM and CMS Analyzer
are in chronological order and that the first data set input
to DAY080 contains domain 1 records. Otherwise, the result
is unpredictable.
