7. PARAMETERS › 7.3 Unit Level Parameters › 7.3.1 DB2 Processing Options (DB2OPS) › 7.3.1.3 Incremental Update Statements
7.3.1.3 Incremental Update Statements
INCRUPDATE
----------
This statement is optional. Specify this to enable
incremental update for this product:
INCRUPDATE YES
If you do not specify or enable the INCRUPDATE parameter,
then this option defaults to this and incremental update is
disabled:
INCRUPDATE NO
*************************************************************
* *
* Note: Changing the INCRUPDATE parameter (either from NO *
* to YES or from YES to NO) requires regeneration *
* of the DAILY operational job by executing *
* prefix.MICS.CNTL(JCLGEND) or by specifying *
* DAILY in prefix.MICS.PARMS(JCLGENU) and *
* executing prefix.MICS.CNTL(JCLGENU). *
* *
* If you specify INCRUPDATE YES, you must also *
* generate the INCRccc, cccIUALC, and cccIUGDG jobs *
* (where ccc is the 3 character product ID). *
* Depending on the options you select, you may also *
* need to execute the cccIUALC and/or cccIUGDG *
* jobs. *
* *
*************************************************************
Incremental update can significantly reduce time and resource
usage in the DAILY job by letting you split out a major
portion of daily database update processing into multiple,
smaller, incremental updates executed throughout the day.
o Standard CA MICS database update processing involves (1)
reading and processing raw input data to generate DETAIL
and DAYS level CA MICS database files, followed by (2)
summarization of DETAIL/DAYS level data to update
week-to-date and month-to-date database files.
o When you activate incremental update:
- You can execute the first-stage processing (raw data
input to create DETAIL/DAYS files) multiple times
throughout the day, each time processing a subset of
the total day's input data.
- Then, during the final update of the day (in the
DAILY job), the incremental DETAIL/DAYS files are
"rolled-up" to the database DETAIL and DAYS
timespans, and then summarized to update the
week-to-date and month-to-date files.
o Incremental update is independent of your internal step
restart or DBSPLIT specifications. You have the option
to perform incremental updates with or without internal
step restart support.
o Incremental update is activated and operates
independently by product. The incremental update job
for this product, INCRccc (where ccc is the product ID),
can execute concurrently with the incremental update job
for another product in the same unit database.
o The CA MICS database remains available for reporting and
analysis during INCRccc job execution.
*************************************************************
* *
* Note: CA MICS is a highly configurable system *
* supporting up to 36 unit databases, each of which *
* can be configured and updated independently. *
* Incremental update is just one of the options you *
* can use to configure your CA MICS complex. *
* *
* All efforts should be made to employ CA MICS *
* configuration capabilities to minimize issues *
* prior to activating incremental update. For *
* example: *
* *
* o Splitting work to multiple units is an *
* effective way to enable parallel database *
* update processing *
* *
* o Adjusting account code definitions to ensure *
* adequate data granularity while minimizing *
* total database space and processing time *
* *
* o Tailoring the database to drop measurements *
* and metrics of lesser value to your *
* data center, thereby reducing database update *
* processing and resource consumption *
* *
* While incremental update is intended to reduce *
* DAILY job elapsed time, total resource usage of *
* the combined INCRccc and DAILY jobs steps can *
* increase due to the additional processing *
* required to maintain the incremental update *
* "to-date" files and for roll-up to the unit *
* database. The increased total resource usage *
* will be more noticeable with small data volumes, *
* where processing code compile time is a greater *
* percentage of total processing cost. *
* *
*************************************************************
Note: When you activate incremental update (INCRUPDATE YES),
the following optional incremental update parameters are
enabled. These parameters have no effect if incremental
update is disabled (INCRUPDATE NO). For more details, see
the individual parameter descriptions later in this section.
o INCRDB PERM/TAPE/DYNAM
o INCRDETAIL data_set_allocation_parameters
o INCRDAYS data_set_allocation_parameters
o INCRCKPT data_set_allocation_parameters
o INCRSPLIT USE/IGNORE data_set_allocation_parameters
Incremental update processing reads and processes raw
measurement data to create and maintain DETAIL and DAYS level
"to-date" files for the current day.
o These incremental update database files are maintained on
unique z/OS data sets, independent of the standard CA MICS
database files, and independent of any other product's
incremental update database files. There is one data set
each for DETAIL and DAYS level "to-date" data and a single
incremental update checkpoint data set for this product in
this unit.
o The incremental update DETAIL and DAYS files can be
permanent DASD data sets, or they can be allocated
dynamically as needed and deleted after DAILY job
processing completes. Optionally, you can keep the
incremental update DETAIL and DAYS files on tape, with
the data being loaded onto temporary DASD space as
needed for incremental update or DAILY job processing.
See the INCRDB PERM/TAPE/DYNAM option for more
information.
After activating incremental update, you will use three
incremental update facility jobs found in prefix.MICS.CNTL
(Note that ccc is the product ID):
o cccIUALC
You execute this job to allocate and initialize the
incremental update checkpoint file, and optionally the
incremental update DETAIL and DAYS database files.
cccIUALC is generally executed just ONE time.
o cccIUGDG
You execute this job to add generation data group (GDG)
index definitions to your system catalog in support of
the INCRDB TAPE option. cccIUGDG is generally executed
just ONE time.
o INCRccc
This is the job you execute for each incremental update.
You will integrate this job into your database update
procedures for execution one or more times per day
to process portions of the total day's measurement data.
Note: The DAILY job is run once at the end of the day.
It will perform the final incremental update for the day's
data, and then roll-up the incremental DETAIL/DAYS files
to the database DETAIL and DAYS timespans and update the
week-to-date and month-to-date files.
INCRUPDATE Considerations
-------------------------
o Overhead
Incremental update is intended to reduce DAILY job
resource consumption and elapsed time by offloading a
major portion of database update processing to one or
more executions of the INCRccc job. In meeting this
objective, incremental update adds processing in the
INCRccc and DAILY jobs to accumulate data from each
incremental update execution into the composite "to-date"
DETAIL and DAYS incremental update files, and also adds
processing in the DAILY job to copy the incremental
update files to the unit database DETAIL and DAYS
timespans. The amount of this overhead and the savings in
the DAILY job are site-dependent, and will vary based on
input data volume and on the number of times INCRccc is
executed each day.
In addition, activating incremental update will cause
additional compile-based CPU time to be consumed in the
DAYnnn DAILY job step. The increase in compile time is
due to additional code included for each file structure in
support of the feature. This increase should be static
based on the scope of the CA MICS data integration product
in terms of files. This compile-time increase does not
imply an increase in elapsed or execution time.
Incremental update allows I/O bound, intensive processing
(raw data inputting, initial CA MICS transformation, etc.)
to be distributed outside of the DAILY job. I/O
processing is the largest contributor to elapsed time in
large volume applications. Thus, the expected overall
impact is a decrease in the actual runtime of the DAYnnn
job step.
o Increased "Prime Time" Workload
By offloading work from the DAILY job to one or more
INCRccc executions throughout the day, you are
potentially moving system workload and DASD work space
usage from the "off-hours," (when the DAILY job is
normally executed) to periods of the day where your
system resources are in highest demand. You should
schedule INCRccc executions carefully to avoid adverse
impact to batch or online workloads. For example, if your
site's "prime shift" is 8:00 AM to 5:00 PM, you might
choose to schedule incremental updates for 7:00 AM (just
before "prime shift") and 6:00 PM (just after "prime
shift"), with the DAILY job executing just after midnight.
o Increased DASD Usage
The DASD space required for the incremental update DETAIL
and DAYS database files is in addition to the DASD space
already reserved for the CA MICS database. By default,
the incremental update database files are permanently
allocated, making this DASD space unavailable for other
applications. In general, you can assume that the
incremental update database files will require space
equivalent to two cycles of this product's DETAIL and
DAYS timespan files.
Alternatively, the incremental update database files can
be allocated in the first incremental update of the day
and deleted by the DAILY job (see the INCRDB DYNAM option
later in this section). This approach reduces the amount
of time that the DASD space is dedicated to incremental
update, and lets the amount of DASD space consumed
increase through the day as you execute each incremental
update.
A third option is to store the incremental update
database files on tape (see the INCRDB TAPE option).
With this approach, the DASD space is required just for
the time that each incremental update or DAILY job step
is executing. Note that while this alternative reduces
the "permanent" DASD space requirement, the total amount
of DASD space required while the incremental update or
DAILY jobs are executing is unchanged. In addition, the
TAPE option adds processing to copy the incremental
update files to tape, and to reload the files from tape
to disk.
Note: The incremental update checkpoint file is always a
permanently allocated disk data set. This is a small data
set and should not be an issue.
o Operational Complexity
Incremental update expands your measurement data
management and job scheduling issues. You must ensure
that each incremental update and the DAILY job processes
your measurement data chronologically; that is, each job
must see data that is newer than the data processed by the
prior job. By incrementally updating the database, you
have more opportunities to miss a log file, or to process
a log out of order.
o Interval End Effects
Each incremental update processes a subset of the day's
measurement data, taking advantage of early availability
of some of the day's data, for example, when a
measurement log fills and switches to a new volume. This
can cause a problem if the measurement log split occurs
while the data source is logging records for the end of a
measurement interval, thus splitting the data for a
single measurement interval across two log files. When
an incremental update processes the first log file, the
checkpoint high end timestamp is set to indicate that
this split measurement interval has been processed.
Then, when the rest of the measurement interval's data is
encountered in a later update, it can be dropped as
duplicate data (because data for this measurement
interval end timestamp has already been processed).
Appropriate scheduling of log dumps and incremental
updates can avoid this problem. For example, if you plan
to run incremental updates at 7:00 AM and 6:00 PM, you
could force a log dump in the middle of the measurement
interval just prior to the scheduled incremental update
executions. This is an extension of the procedure you
may already be using for end-of-day measurement log
processing. The objective is to ensure that all records
for each monitor interval are processed in the same
incremental update.
o Dynamic Allocation
When you activate incremental update and specify TAPE or
DYNAM for the INCRDB parameter, dynamic allocation is
employed for the incremental update database files. If
your site restricts dynamic allocation of large, cataloged
data sets, you must use the INCRDETAIL and INCRDAYS
parameters to direct incremental update data set
allocation to a generic unit or storage class where
dynamic allocation is allowed.
o Data Set Names
The incremental update database files are allocated and
cataloged according to standard CA MICS unit database
data set name conventions. The DDNAME and default data
set names are (where ccc is the product ID):
o Incremental update checkpoint file,
//IUCKPT DD DSN=prefix.MICS.ccc.IUCKPT,.....
o Incremental update DETAIL
//IUDETAIL DD DSN=prefix.MICS.ccc.IUDETAIL,.....
o Incremental update DAYS
//IUDAYS DD DSN=prefix.MICS.ccc.IUDAYS,....
Since these data sets conform to the same data set name
conventions as your existing CA MICS data sets, there
should be few, if any, data-set-name-related allocation
issues. However, it is possible to override the data set
names if required. Contact Technical Support at
http://ca.com/support for assistance if you must change
data set names.
*************************************************************
* *
* Note: If your data center uses the TAPEfff option *
* or USRXfff exits, be sure to review the *
* important considerations in Section 10.3.1 of *
* this guide. *
* *
*************************************************************
INCRDB
------
This statement is optional. The default is this:
INCRDB PERM
Note: INCRDB is ignored when you specify INCRUPDATE NO.
Specify this or take the default, to keep the incremental
update database DETAIL and DAYS files on permanently
allocated DASD data sets:
INCRDB PERM
Execute the prefix.MICS.CNTL(cccIUALC) job to allocate the
incremental update database files.
*************************************************************
* *
* Note: The incremental update checkpoint file is always *
* a permanently allocated DASD data set. *
* *
*************************************************************
Specify this to offload the incremental update DETAIL and
DAYS files to tape between incremental update executions:
INCRDB TAPE #gdgs UNIT=name
With the TAPE option, the incremental update DETAIL and DAYS
DASD data sets are dynamically allocated at the beginning of
the incremental update job or DAILY job step, and then are
deleted after the job step completes.
o The first incremental update job of the day allocates
and initializes the incremental update database files.
At the end of the job, the DETAIL and DAYS files are
copied to a new (+1) generation of the incremental
update tape data sets. Then the DASD files are deleted.
o Subsequent incremental update jobs restore the DASD
incremental update database files from the current, (0)
generation, incremental update tape data sets before
processing the input measurement data. At the end of
the job, the DETAIL and DAYS files are copied to a new
(+1) generation of the incremental update tape data
sets. Then the DASD files are deleted.
o The DAILY job step also restores the DASD incremental
update database files from the (0) generation tape files
before processing the input data, but does NOT copy the
incremental update database files to tape. Thus, the
DAILY job actually creates a new, null (+1) generation.
o Use the #gdgs parameter to specify the maximum number of
incremental update tape generations. The minimum is 2
and the maximum is 99, with a default of 5. You should
set the number of generations equal to or greater than
the number of incremental updates, including the DAILY
job you plan to execute each day. This will facilitate
restart and recovery if you encounter problems requiring
you to reprocess portions of the day's measurement data.
o Use the optional UNIT=name parameter to specify a tape
unit name for the incremental update database output
tapes. The default is to use the same tape unit as the
input tapes.
o A special index must be created in your system catalog for
each of the incremental update tape data set generation
data groups. The prefix.MICS.CNTL(cccIUGDG) job will
generate the statements to create the incremental update
GDG index definitions. The statements are generated for
either a VSAM or CVOL (control volume) catalog according
to your prefix.MICS.PARMS(JCLDEF) specifications.
- Before each index is built, it is deleted. These
DLTX (or DELETE) statements will cause an error
message if no entry exists. This is done so that you
can change the number of entries without having to
delete each of the index entries.
- DLTX and BLDG (or DELETE and DEFINE) will fail if
there is a cataloged data set with the same index.
IDCAMS (or IEHPROGM) will issue a message and give
a return code of 8. This is not a problem for
non-GDG entries or if the GDG already has the
desired number of entries.
- If you want to change the number of entries kept in
a GDG with cataloged data sets, you must do the
following:
1. Uncatalog any existing entries in the GDG.
2. Delete the index with a DLTX (or DELETE).
3. Create the index with a BLDG (or DEFINE).
4. Catalog any entries uncataloged in step 1.
o The incremental update tape data set names are as follows,
where ccc is the product ID:
- Incremental update tape DETAIL file
tapeprefix.MICS.ccc.IUXTAPE.GnnnnV00
- Incremental update tape DAYS file
tapeprefix.MICS.ccc.IUDTAPE.GnnnnV00
*************************************************************
* *
* Note: The INCRDETAIL and INCRDAYS parameters are *
* required when you specify INCRDB TAPE. *
* *
*************************************************************
Specify this to dynamically allocate the incremental update
DETAIL and DAYS DASD data sets in the first incremental
update of the day, and then delete these data sets at the end
of the DAILY job step:
INCRDB DYNAM
o With this option, no space is used for the incremental
update database files during the time between the end of
the DAILY job step and the beginning of the next day's
first incremental update.
o With this approach, you can set the data set allocation
parameters so that the incremental update DETAIL and DAYS
data sets start out with a minimum allocation (for
example, enough space for one incremental update) and then
grow through secondary allocations as additional space is
required for subsequent incremental updates.
*************************************************************
* *
* Note: The INCRDETAIL and INCRDAYS parameters are *
* required when you specify INCRDB DYNAM. *
* *
*************************************************************
INCRDETAIL
----------
This statement is required if you specify either of these:
INCRDB TAPE
INCRDB DYNAM
Otherwise, this statement is optional. There is no default.
Specify this to define data set allocation parameters for the
incremental update DETAIL data set (IUDETAIL):
INCRDETAIL data_set_allocation_parameters
Note: INCRDETAIL is ignored when you specify INCRUPDATE NO.
The incremental update DETAIL data set (IUDETAIL) contains
the current incremental update detail-level database files,
and the DETAIL "to-date" data for the current daily update
cycle. You should allocate DASD space equivalent to two
cycles of this product's DETAIL timespan data.
If you specified INCRDB PERM (the default), your INCRDETAIL
parameter specifications are used in generating the cccIUALC
job (where ccc is the product ID).
o You will execute the cccIUALC job to allocate and
initialize the incremental update database and checkpoint
files.
o Omit the INCRDETAIL parameter if you prefer to specify
data set allocation parameters directly in the generated
prefix.MICS.CNTL(cccIUALC) job.
If you specified INCRDB TAPE or INCRDB DYNAM, your INCRDETAIL
parameter specifications are used in incremental update
DETAIL data set dynamic allocation during incremental update
or DAILY job step execution.
o The INCRDETAIL parameter is required for the TAPE or
DYNAM option.
o Specify data set allocation parameters, separated by
blanks, according to SAS LIBNAME statement syntax. If
you need multiple lines, repeat the INCRDETAIL keyword
on the continuation line.
o INCRDETAIL accepts the engine/host options documented in
the SAS Companion for the z/OS Environment, including
STORCLAS, UNIT, SPACE, BLKSIZE, DATACLAS, MGMTCLAS, and
VOLSER.
Important! DO NOT SPECIFY THE DISP PARAMETER.
o You can override the INCRDETAIL data set allocation
parameters at execution-time using the //PARMOVRD
facility. For more information about execution-time
override of dynamic data set allocation parameters, see
the PIOM, section 2.3.6.
Example 1:
INCRDETAIL STORCLAS=MICSTEMP SPACE=(xxxx,(pp,ss),,,ROUND)
where:
STORCLAS - specifies a storage class for a new data set.
The name can have up to eight characters.
SPACE - specifies how much disk space to provide for
a new data set being allocated, where:
xxxx is TRK, CYL, or blklen
pp is the primary allocation
ss is the secondary allocation
and ROUND specifies that the allocated space be
"rounded" to a cylinder boundary when the unit
specified was a block length. ROUND is ignored
with the TRK or CYL options.
Example 2 (multiple lines):
INCRDETAIL STORCLAS=MICSTEMP UNIT=SYSDA
INCRDETAIL SPACE=(xxxx,(pp,ss),,,ROUND)
where:
STORCLAS - specifies a storage class for a new data set.
The name can have up to eight characters.
UNIT - specifies the generic unit for a new data set.
The name can have up to eight characters.
SPACE - specifies how much disk space to provide for
a new data set being allocated.
INCRDAYS
--------
This statement is required if you specify either of these:
INCRDB TAPE
INCRDB DYNAM
Otherwise, this statement is optional. There is no default.
Specify this to define data set allocation parameters for the
incremental update DAYS data set (IUDAYS):
INCRDAYS data_set_allocation_parameters
Note: INCRDAYS is ignored when you specify INCRUPDATE NO.
The incremental update DAYS data set (IUDAYS) contains the
current incremental update days-level database files, and the
DAYS "to-date" data for the current daily update cycle. You
should allocate DASD space equivalent to two cycles of this
product's DAYS timespan data.
If you specified INCRDB PERM (the default), your INCRDAYS
parameter specifications are used in generating the cccIUALC
job (where ccc is the product ID).
o You will execute the cccIUALC job to allocate and
initialize the incremental update database and checkpoint
files.
o Omit the INCRDAYS parameter if you prefer to specify
data set allocation parameters directly in the generated
prefix.MICS.CNTL(cccIUALC) job.
If you specified INCRDB TAPE or INCRDB DYNAM, your INCRDAYS
parameter specifications are used in incremental update DAYS
data set dynamic allocation during incremental update or
DAILY job step execution.
o The INCRDAYS parameter is required for the TAPE or DYNAM
option.
o Specify data set allocation parameters, separated by
blanks, according to SAS LIBNAME statement syntax. If
you need multiple lines, repeat the INCRDAYS keyword on
the continuation line.
o INCRDAYS accepts the engine/host options documented in the
SAS Companion for the z/OS Environment, including
STORCLAS, UNIT, SPACE, BLKSIZE, DATACLAS, MGMTCLAS, and
VOLSER.
Important! DO NOT SPECIFY THE DISP PARAMETER.
o You can override the INCRDAYS data set allocation
parameters at execution-time using the //PARMOVRD
facility. For more information about execution-time
override of dynamic data set allocation parameters, see
the PIOM, Section 2.3.6.
Example 1:
INCRDAYS STORCLAS=MICSTEMP SPACE=(xxxx,(pp,ss),,,ROUND)
where:
STORCLAS - specifies a storage class for a new data set.
The name can have up to eight characters.
SPACE - specifies how much disk space to provide for
a new data set being allocated, where:
xxxx is TRK, CYL, or blklen
pp is the primary allocation
ss is the secondary allocation
and ROUND specifies that the allocated space be
"rounded" to a cylinder boundary when the unit
specified was a block length. ROUND is ignored
with the TRK or CYL options.
Example 2 (multiple lines):
INCRDAYS STORCLAS=MICSTEMP UNIT=SYSDA
INCRDAYS SPACE=(xxxx,(pp,ss),,,ROUND)
where:
STORCLAS - specifies a storage class for a new data set.
The name can have up to eight characters.
UNIT - specifies the generic unit for a new data set.
The name can have up to eight characters.
SPACE - specifies how much disk space to provide for
a new data set being allocated.
INCRCKPT
--------
This statement is optional. Specify this to override default
data set allocation parameters for the incremental update
checkpoint data set:
INCRCKPT data_set_allocation_parameters
Note: INCRCKPT is ignored when you specify INCRUPDATE NO.
The incremental update checkpoint data set tracks incremental
update job status and the data that has been processed during
the current daily update cycle. The incremental update
checkpoint is used to detect and block the input of duplicate
data during incremental update processing. This data set
will be exactly the same size as prefix.MICS.CHECKPT.DATA
(the unit checkpoint data set), usually 20K to 200K depending
on the prefix.MICS.PARMS(SITE) CKPTCNT parameter (100-1000).
Your INCRCKPT parameter specifications are used in generating
the cccIUALC job (where ccc is the product ID).
o You will execute the cccIUALC job to allocate and
initialize the incremental update checkpoint file. If you
specified INCRDB PERM, then the cccIUALC job will also
allocate the incremental update DETAIL and DAYS database
files.
o By default the incremental update checkpoint data set is
allocated as SPACE=(TRK,(5,2)) using the value you
specified for the prefix.MICS.PARMS(JCLDEF) DASDUNIT
parameter.
o Omit the INCRCKPT parameter if you prefer to override
data set allocation parameters directly in the generated
prefix.MICS.CNTL(cccIUALC) job.
Specify data set allocation parameters, separated by blanks,
according to SAS LIBNAME statement syntax. If you need
multiple lines, repeat the INCRCKPT keyword on the
continuation line.
INCRCKPT accepts the engine/host options documented in the
SAS Companion for the MVS Environment, including STORCLAS,
UNIT, SPACE, BLKSIZE, DATACLAS, MGMTCLAS, and VOLSER.
Important! DO NOT SPECIFY THE DISP PARAMETER.
Example 1:
INCRCKPT STORCLAS=MICSTEMP SPACE=(xxxx,(pp,ss),,,ROUND)
where:
STORCLAS - specifies a storage class for a new data set.
The name can have up to eight characters.
SPACE - specifies how much disk space to provide for
a new data set being allocated, where:
xxxx is TRK, CYL, or blklen
pp is the primary allocation
ss is the secondary allocation
and ROUND specifies that the allocated space be
"rounded" to a cylinder boundary when the unit
specified was a block length. ROUND is ignored
with the TRK or CYL options.
Example 2 (multiple lines):
INCRCKPT STORCLAS=MICSTEMP UNIT=SYSDA
INCRCKPT SPACE=(xxxx,(pp,ss),,,ROUND)
where:
STORCLAS - specifies a storage class for a new data set.
The name can have up to eight characters.
UNIT - specifies the generic unit for a new data set.
The name can have up to eight characters.
SPACE - specifies how much disk space to provide for
a new data set being allocated.
INCRSPLIT
---------
This statement is optional and defaults to this:
INCRSPLIT IGNORE
Specify the following if you want the incremental update job
for this product to get input measurement data from the
output of the SPLITSMF job. The optional
data_set_allocation_parameters are used by the SPLITSMF job
when creating the measurement data file for this product.
INCRSPLIT USE data_set_allocation_parameters
Note: INCRSPLIT is ignored when you specify INCRUPDATE NO.
This option would be used when multiple products in a
single unit database are enabled to incremental update. The
SPLITSMF job performs the same function for incremental
update jobs as the DAILY job DAYSMF step performs for the
DAYnnn database update steps.
o The SPLITSMF job dynamically allocates, catalogs, and
populates prefix.MICS.ccc.IUSPLTDS data sets for each
product in the unit database for which you specified both
the INCRUPDATE YES and INCRSPLIT USE parameters. These
data sets are then deleted after processing by the
appropriate INCRccc job.
o Specify data set allocation parameters, separated by
blanks, according to SAS LIBNAME statement syntax. If you
need multiple lines, repeat the INCRSPLIT keyword on each
continuation line.
o INCRSPLIT accepts the engine/host options documented in
the SAS Companion for the MVS Environment, including
STORCLAS, UNIT, SPACE, BLKSIZE, DATACLAS, MGMTCLAS, and
VOLSER.
Important! DO NOT SPECIFY THE DISP PARAMETER.
Specify the following or accept the default if you want the
incremental update jobs for this product to get their input
measurement data from the data sets specified in the INPUTccc
(or INPUTSMF) member of prefix.MICS.PARMS:
INCRSPLIT IGNORE
When you specify INCRSPLIT IGNORE, this product will NOT
participate in SPLITSMF job processing.
Example 1:
INCRSPLIT USE STORCLAS=MICSTEMP SPACE=(xxxx,(pp,ss),,,ROUND)
where:
STORCLAS - specifies a storage class for a new data set.
The name can have up to eight characters.
SPACE - specifies how much disk space to provide for
a new data set being allocated, where:
xxxx is TRK, CYL, or blklen
pp is the primary allocation
ss is the secondary allocation
and ROUND specifies that the allocated space be
"rounded" to a cylinder boundary when the unit
specified was a block length. ROUND is ignored
with the TRK or CYL options.
Example 2 (multiple lines):
INCRSPLIT USE STORCLAS=MICSTEMP UNIT=SYSDA
INCRSPLIT SPACE=(xxxx,(pp,ss),,,ROUND)
where:
STORCLAS - specifies a storage class for a new data set.
The name can have up to eight characters.
UNIT - specifies the generic unit for a new data set.
The name can have up to eight characters.
SPACE - specifies how much disk space to provide for
a new data set being allocated.
DYNAMWAIT
---------
This statement is optional. Specify the following:
DYNAMWAIT minutes
to override the default amount of time, in minutes, the DAILY
and/or INCRccc job will wait for an unavailable data set.
Note: This optional parameter is not normally specified.
The system default is adequate for most data centers.
Internal Step Restart and Incremental Update facilities use
z/OS dynamic allocation services to create new data sets and
to access existing data sets. Data set naming conventions
and internal program structure are designed to minimize data
set contention. However, if data set allocation does fail
because another batch job or online user is already using a
data set, DAILY and/or INCRccc processing will wait 15
seconds and then try the allocation again. By default, the
allocation will be attempted every 15 seconds for up to 15
minutes. After 15 minutes, the DAILY or INCRccc job will
abort.
If data set contention in your data center does cause
frequent DAILY or INCRccc job failures, and you are unable to
resolve the contention through scheduling changes, you may
want to use the DYNAMWAIT parameter to increase the maximum
number of minutes the DAILY and/or INCRccc jobs will wait for
the data set to become available.
On the other hand, if your data center standards require
that the DAILY and/or INCRccc jobs fail immediately if
required data sets are unavailable, specify the following:
DYNAMWAIT 0
Note: You can override the DYNAMWAIT parameter at
execution-time using the //PARMOVRD facility. For
more information about execution-time override of
dynamic data set allocation parameters, see the PIOM,
section 2.3.6.
The following section discusses enabling this option:
1 - Implement Incremental Update
