5. MICF Administration › 5.1 Tasks Performed During Installation › 5.1.6 Production Reporting › 5.1.6.4 MICF Inquiry Production Interface
5.1.6.4 MICF Inquiry Production Interface
You can generate and catalog color graphics and printed
reports with the regularly scheduled CA MICS production jobs
(for example, the daily CA MICS update). The MICF inquiry
production interface automatically schedules production
reporting based on the CA MICS production job association you
define. Use the CA MICS Job parameter to specify the
production CA MICS job (for example, DAILY, WEEKLY, or
MONTHLY) to schedule the production reporting. If CA MICS
Job is DAILY, WEEKLY, or MONTHLY, use the DB ID parameter to
identify the CA MICS database unit to which the CA MICS Job
specification applies. If you do not associate the
production reporting jobstream with a CA MICS job, you will
need to use your data center's own scheduling facilities to
schedule the production reporting jobstream.
Note: The calendars used with CA MICS have been defined by
the CA MICS administrator. They control the number of days,
weeks, and months in a year, as well as when weeks, months,
and years start and end. If you have any questions about the
calendars used in your data center, see your CA MICS
administrator. For a technical discussion of calendar
definitions, see Sections 2.3.1.8 and 2.3.2.4 in the PIOM and
4.7 in the System Modification Guide.
Production interface operation depends upon your
specification for the JCLDEF AUTOSUBMIT parameter (see
Section 2.3.3.2.1 in the PIOM).
If AUTOSUBMIT is YES, the DAILY, WEEKLY, and MONTHLY CA MICS
database update jobs submit independent jobs to generate
CA MICS exception and MBO reports (DAILYRPT, WEEKRPT, and
MONTHRPT). The first step of each reporting job executes
MICF inquiry production interface processing. The production
interface looks for production reporting jobstream
definitions associated with this CA MICS production process
(that is, looks for matching associated CA MICS job and DB ID
specifications), and then executes the production reporting
jobstreams. All MICF inquiry production reporting associated
with this CA MICS production job is executed in this single
job step. The second step of the DAILYRPT, WEEKRPT, and
MONTHRPT batch jobs performs the standard CA MICS exception
and MBO report processing.
If AUTOSUBMIT is NO, the CA MICS exception and MBO report
processing occur during the production daily, weekly, and
monthly CA MICS update jobs (in the DAY400, WEEK400, and
MONTH400 steps). MICF inquiry production interface
processing is NOT included in the daily, weekly, or monthly
database update jobs. This is a key point to remember
because CA MICS will NOT automatically schedule the MICF
inquiry production reporting when AUTOSUBMIT is NO.
When AUTOSUBMIT is NO, the DAILYRPT, WEEKRPT, and MONTHRPT
batch jobs are still generated and are available for
execution through your standard batch scheduling facilities.
The first step of the DAILYRPT, WEEKRPT, and MONTHRPT jobs
still provides both the MICF inquiry production interface AND
production reporting jobstream execution. Just like the
AUTOSUBMIT mode, the production interface looks for
production reporting jobstream definitions associated with
this CA MICS production process, and then executes the
production reporting jobstreams. The key difference is that
YOU must schedule the daily, weekly, and monthly report jobs
with your data center's standard batch job scheduling
facilities.
If AUTOSUBMIT is NO and your CA MICS exception and MBO report
processing normally occurs during the production daily,
weekly, and monthly CA MICS update jobs, you may want to
schedule the individual job steps shown below rather than
the entire DAILYRPT, WEEKRPT, and MONTHRPT jobs.
The example JCL shown below is taken directly from the first
step of the DAILYRPT, WEEKRPT, and MONTHRPT jobs,
respectively.
DAILY PROCESSING - MICF INQUIRY PRODUCTION INTERFACE
//ICFDY400 EXEC MICSRPTS
//SYSTSIN DD DISP=SHR,DSN=sharedprefix.MICS.SOURCE(ICFJD400)
//ICFPARMS DD DISP=SHR,DSN=prefix.MICS.PARMS(DBCONFIG)
WEEKLY PROCESSING - MICF INQUIRY PRODUCTION INTERFACE
//ICFWK400 EXEC MICSRPTS
//SYSTSIN DD DISP=SHR,DSN=sharedprefix.MICS.SOURCE(ICFJW400)
//ICFPARMS DD DISP=SHR,DSN=prefix.MICS.PARMS(DBCONFIG)
MONTHLY PROCESSING - MICF INQUIRY PRODUCTION INTERFACE
//ICFMN400 EXEC MICSRPTS
//SYSTSIN DD DISP=SHR,DSN=sharedprefix.MICS.SOURCE(ICFJM400)
//ICFPARMS DD DISP=SHR,DSN=prefix.MICS.PARMS(DBCONFIG)
AVAILABILITY OF CATALOG TABLE DATA SET
You should be aware that production reporting will fail if
the catalog table data set for a production reporting
jobstream is not available (that is, if it is held DISP=OLD
by another job or user). Catalog table data sets are
normally held DISP=OLD only when you are updating the
production reporting definition or deleting production
catalog outputs (that is, when you enter the S, select, or D,
delete, line commands on the Production Reporting
Administration panel). Since production reporting normally
occurs overnight, the exposure should be minimal. In
addition, there is no conflict between executing a production
reporting jobstream (that is, updating reports) while one or
more users review prior reports online. In other words, you
do NOT have to tell your manager to quit looking at online
reports so you can run the daily report job.
However, if you find that production reporting jobs ABEND due
to contention for one or more production reporting catalog
table data sets, you can use your data center's standard
batch scheduling facilities to submit and control MICF
inquiry production reporting instead of letting the CA MICS
daily, weekly, and monthly production processing schedule
MICF inquiry production reporting. To do this, simply blank
out the associated CA MICS job field for each production
reporting jobstream definition (see the Reports and Graphics
Jobstream panel, Figure 5-6) and set up production jobs to
execute specific MICF inquiry production reporting
jobstreams. See Executing a Production Reporting Jobstream
in Section 5.1.6.3 for more information.
If you specify YES for the AUTOSUBMIT parameter in
prefix.MICS.PARMS(JCLDEF), you can instruct the DAILYRPT,
WEEKRPT, and MONTHRPT jobs to submit an additional batch job
to process the production reporting jobstreams. This
generated batch job uses the JOB statement and EXEC statement
specifications from the DAILYRPT/WEEKRPT/MONTHRPT job (for
example, has the same job name) and includes a DD statement
to allocate each associated production reporting jobstream
catalog table data set. Since JES will handle data set
enqueue conflicts, you will not be bothered by ABENDs due to
an unavailable catalog table data set. To implement this
approach, add or change
MICFRPTS SUBMIT
to prefix.MICS.PARMS(JCLDEF) and submit the batch job in
prefix.MICS.CNTL(JCLGEND) for each unit.
WHY MICF INQUIRY PRODUCTION REPORTING DOES NOT OCCUR DURING
UPDATE JOBS
MICF inquiry production interface processing does not occur
during the CA MICS production daily, weekly, and monthly
update jobs for the following reasons:
o Running reports during the database update job elongates
database update processing and delays database
availability. By doing reporting outside the database
update (that is, after the database update completes), you
do not have to wait until all the reports complete before
you can make on demand inquiries into the database.
o If you use your data center's production batch job
scheduling facilities to submit a separate batch job for
each MICF inquiry production reporting jobstream, MICF
reporting can execute in parallel so that reports are
available earlier in the morning.
o Running reports during the database update means that any
problem that causes the reporting process to ABEND (for
example, an enqueue conflict for a MICF inquiry production
reporting jobstream catalog table data set) will terminate
the database update, thereby delaying all processing until
the reporting problem is corrected.
o The MICF inquiry production reporting process requires a
batch TMP (that is, executes TSO and ISPF in batch mode).
Using a batch TMP in a production database update job adds
the additional exposure that ISPF or TSO changes could
cause the database update job to fail.
o And finally, a security/change control consideration:
MICF inquiry production reporting facilities are designed
so that you can change your production reporting without
CA MICS generation processing. And since you can
distribute production reporting administration duties (for
example, you can let the Accounting staff control their
own accounting daily/weekly/monthly reports), your
production database update processing stream could change
outside of your data center's normal change control
procedures. By keeping MICF inquiry production reporting
external to production database update processing, you
avoid this exposure.
COMPLEX LEVEL REPORTING
The prior discussion deals with MICF inquiry production
interface processing relative to the CA MICS production
daily, weekly, and monthly database updates. However, the
MICF inquiry production interface facilities can be applied
to other production situations. For example, if your data
center's production batch job scheduling facility submits a
daily reporting job after ALL CA MICS database unit update
jobs complete (that is, your scheduler submits the reporting
job after the primary, CICS, IMS, and SNA Network database
updates complete), you can use the MICF inquiry production
interface to schedule MICF inquiry production reporting with
this "complex-level" reporting process.
Use the following JCL statements to add MICF inquiry
production interface processing to a CA MICS related job in
order to automatically generate associated reports and
graphics. Use a blank value in the CA MICS DB ID parameter
field that associates reporting with the production job.
Then code one of the following three JCL sets (for daily,
weekly, or monthly) to schedule all MICF production reporting
jobstreams that use a blank value for associated CA MICS DB
ID (see the Reports and Graphics Jobstream panel, Figure
5-6).
Daily:
// EXEC MICSRPTS
//SYSTSIN DD DISP=SHR,DSN=sharedprefix.MICS.SOURCE(ICFJD400)
Weekly:
// EXEC MICSRPTS
//SYSTSIN DD DISP=SHR,DSN=sharedprefix.MICS.SOURCE(ICFJW400)
Monthly:
// EXEC MICSRPTS
//SYSTSIN DD DISP=SHR,DSN=sharedprefix.MICS.SOURCE(ICFJM400)
Include an ICFPARMS allocation if you are executing a CA MICS
database unit-related process. MICF scans ICFPARMS to
determine DB ID.
//ICFPARMS DD DISP=SHR,DSN=prefix.MICS.PARMS(DBCONFIG)
If you want the production interface to submit a separate job
for reports and graphics processing, add the following JCL
statements.
//ICFEXRDR DD SYSOUT=(A,INTRDR),
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=80)
//ICFJCNTL DD DISP=SHR,DSN=micf.reporting.jcl.model
MICF copies job, execute, and SYSTSIN DD statements from
ICFJCNTL and adds an ICFRPTnn DD statement for each
associated reporting jobstream. You can use
prefix.MICS.CNTL(DAILYRPT) or prepare your own ICFJCNTL
model, the data set shown above as micf.reporting.jcl.model,
as follows:
//jobname JOB (........
//MICF EXEC MICSRPTS
//SYSTSIN DD DISP=SHR,
// DSN=sharedprefix.MICS.SOURCE(ICFJ100)
