4. Operation › 4.2 Operational Guidelines › 4.2.2 Production Operations › 4.2.2.4 Parallel Database Update Processing
4.2.2.4 Parallel Database Update Processing
CA MICS DAILY job execution for a unit database is a serial
process. Database files are updated in a fixed processing
order by product. Each product must complete daily database
update processing before processing for the next product can
begin. The serial nature of the daily database update
results from ensuring database integrity and requiring
exclusive control of the database before making any
modifications.
If you have installed multiple CA MICS products and/or
process large daily workloads, it is possible that a single,
serial database update for all products is impractical. This
is one reason you might implement multiple unit databases,
spreading this workload over multiple, parallel daily
database update processes. Remember, the database update is
ONLY serial WITHIN a unit. Each unit database is independent
of all other units and thus you can execute database update
jobs for multiple units at the same time.
CA MICS gives you powerful options to address your
installation's unique processing requirements. The ability
to install multiple unit databases is one example of CA MICS'
flexibility. You may choose to implement multiple unit
databases for a number of reasons, for example:
o The input data for different products may become
available at different times of the day. So rather than
waiting for all input data to be available before
starting the daily database update, you split-out one or
more products to one or more additional unit databases,
thereby giving you the flexibility to begin the daily
database update for some products earlier than might have
been possible when all products were in a single unit.
Getting started on daily update processing earlier,
combined with the ability to run database updates for
multiple units concurrently, lets you process more input
data in less time.
o The input data for different systems processed by a
single CA MICS product may become available at different
times of the day. For example, the measurement log for
some CICS regions may be released for CA MICS processing
at a different time than the measurement log for other
CICS regions. Or, you may be processing SMF data from a
remote site, and this SMF data may arrive sometime after
the rest of your SMF data becomes available. So, once
again, rather than waiting for all input data to be
available before starting the daily database update, you
split-out processing for one or more systems (e.g., CICS
regions or SMF data from remote sites) to one or more
additional unit databases, thereby giving you the
flexibility to begin the daily database update for some
systems earlier than might have been possible when all
systems were in a single unit. And, the database updates
for these unique unit databases can run concurrently,
letting you do more in less time.
Parallel database update processing is a common thread in
these two examples, and multiple unit databases is the best
means of achieving such parallelism. However, CA MICS
incremental update facilities can also help you complete your
nightly database update earlier than may be possible with
standard, serial database update processing.
You should normally look to incremental update when you want
to spread database update processing for one or more products
over multiple, smaller incremental updates throughout the
day. Standard incremental update implementation hinges on
the availability of logical subsets of the total day's input
data at times of the day when executing a CA MICS incremental
update does not adversely impact your installation's online
and batch workloads.
You can also use incremental update to achieve a significant
degree of parallelism in database update processing when it
is desirable to keep multiple products in a single unit
database. You should note that incremental update introduces
additional processing costs, operational complexity, and
scheduling considerations, and incremental update provides
less overall benefit than you would receive from spreading
products over multiple units. However, incremental update
can still be a valuable tool in configuring CA MICS to meet
your unique requirements.
The remainder of this section describes daily database update
processing in parallel with incremental update.
Setup and Preparation
The first step is to enable incremental update for one or
more products in the unit database. Refer to the
individual Product Guides for details on activating
incremental update using the product's cccOPS parameter
member. Please follow all instructions carefully, and
run the specified generation and setup jobs. Each
product that supports incremental update provides, in the
Product Guide, a checklist for activating incremental
update.
Examine the generated INCRccc jobs and prepare them for
production execution. In particular, verify that the
INPUTccc and/or INPUTSMF DDs point to the data set(s) that
will contain input data for this product in this unit.
o If you specified the INCRSPLIT USE option in cccOPS,
then the input data set for one or more INCRccc jobs
will be created by the common SPLITSMF job. In this
mode, the INCRccc job dynamically allocates the input
data set (created by the SPLITSMF job), and there is no
INPUTSMF DD statement in the INCRccc job.
o If you are using the SPLITSMF job, then verify that the
INPUTSMF DD statement in the SPLITSMF job points to the
data set that will contain the input SMF data for this
unit.
Examine the re-generated DAILY job and prepare it for
production execution. You will be revising the DAYnnn
steps for the products for which you activated
incremental update so that these job steps will process
no input data. Remember to save your changes in a
separate library so they are not lost when CA MICS
operational jobs are regenerated.
o Add the SYSPARM=NODATA parameter to the EXEC
statement for the DAYSMF step (if present) and the
DAYnnn step for each product for which you activated
incremental update.
o Modify the INPUTccc and/or INPUTSMF DD statements to
specify DD DUMMY (no input data) in DAYnnn steps for
the products for which you enabled incremental
update. If this unit contains a DAYSMF step and
incremental update is active for ALL products in the
unit, specify DD DUMMY (no input data) on the
INPUTSMF DD statement in the DAYSMF step.
Daily Operation
Each day, submit the INCRccc job, either manually or
through your installation's production batch job
scheduling facility, as soon as practical after input
data is available for this product. Individual product
INCRccc jobs can execute in concurrently.
If you specified INCRSPLIT USE in cccOPS for one or more
products, then submit the SPLITSMF job as soon as practical
after SMF input data is available for this unit. Then,
after SPLITSMF completes, submit the INCRccc jobs for each
product for which you specified the INCRSPLIT USE option.
After all INCRccc jobs for this unit complete execution,
submit the normal CA MICS daily database update
processing using one of the techniques described in the
prior sections. For example, you may choose to submit
the CA MICS SCHEDULE job, either manually or through your
installation's production batch job scheduling facility,
or you might use the CA MICS Operational Status and
Tracking Facility SCHEDULE command.
