Batch Management Overview

Batch CA Dataquery is available to allow long running or high-volume queries to be processed without consuming online system resources. You can effectively improve online performance by taking advantage of this batch processing capability.
datacom151
Batch
CA Dataquery™ for CA Datacom®
is available to allow long running or high-volume queries to be processed without consuming online system resources. You can effectively improve online performance by taking advantage of this batch processing capability.
When a user executes queries or dialogs in batch, two choices are available: Batch Sign/On and Batch Online SUBMIT. In Batch Sign/On, the user must create or adapt and use JCL with a product other than
CA Dataquery™ for CA Datacom®
from which the JCL and the input
CA Dataquery™ for CA Datacom®
statements are submitted to the operating system for batch execution. In Batch Online SUBMIT, the user uses a
CA Dataquery™ for CA Datacom®
online panel to
submit
CA Dataquery™ for CA Datacom®
JCL from a
CA Dataquery™ for CA Datacom®
library that carries instructions for query execution. Both types of batch query execution take place offline, conserving resources for online use. The online facilities of
CA Dataquery™ for CA Datacom®
do not have to be up for batch
CA Dataquery™ for CA Datacom®
execution. The execution JCL for batch
CA Dataquery™ for CA Datacom®
points to the load libraries containing the
CA Dataquery™ for CA Datacom®
modules.
One or more users can be given
CA Dataquery™ for CA Datacom®
Administrator authorization for creating and maintaining the
CA Dataquery™ for CA Datacom®
online JCL libraries. The
CA Dataquery™ for CA Datacom®
Administrator maintains the JCL and provides end users with information about which JCL members are appropriate (if the user is given JCL member names in order to be able to use more than one JCL member). With Batch Online SUBMIT, the
CA Dataquery™ for CA Datacom®
Administrator can also create JCL PROCs which permit users to change specific values in a JCL member, as needed.
The following sections provide background information about
CA Dataquery™ for CA Datacom®
JCL statements, along with examples. For authoritative advice regarding the use of JCL statements, see your systems programmer.
Batch Execution Method Comparison
Two methods of batch execution work with
CA Dataquery™ for CA Datacom®
: Batch Online and Batch Signon. Both methods require submitting JCL that contains the information needed by
CA Dataquery™ for CA Datacom®
to process the query. Batch Online JCL is submitted from the Batch Execution panel and does not require signon or
CA Dataquery™ for CA Datacom®
input statements. Those items are provided by the online system. Batch Sign/On is submitted from another product and submits JCL and
CA Dataquery™ for CA Datacom®
statements as part of the job stream. Batch Sign/On requires control cards that may specify various options and must specify the statements for any query or dialog to be executed. The following table shows significant differences between these two batch methods:
Difference
Batch Online SUBMIT
Batch Sign/On
Requires control statements after the input statement.
No
Yes
Permits the use of #DQOPERATORNAME as
the JCL user ID, allowing ID substitution.
Yes
No
Permits the use of variables.
Yes
No
Batch Online SUBMIT
End users can be authorized by the
CA Dataquery™ for CA Datacom®
Administrator to submit batch jobs with an online panel called Batch Execution (DQE40). This panel submits a JCL member containing information needed to process the query. Maintaining the JCL member is a
CA Dataquery™ for CA Datacom®
Administrator responsibility.
Users can submit queries or dialogs for batch execution with a panel in online
CA Dataquery™ for CA Datacom®
and the jobs will execute offline either immediately or at a deferred time.
As the
CA Dataquery™ for CA Datacom®
Administrator, you can create JCL PROCs for users of Batch Online, permitting users to perform variable substitution. See Creating a JCL PROC for Online Submission for details.
CA Dataquery™ for CA Datacom®
Administrator information about Batch Online appears in Batch Online Management.
Batch Sign/On
The Batch Sign/On method requires JCL that submits
CA Dataquery™ for CA Datacom®
statements to the operating system from another product and processes a query or dialog. End users do not commonly use Batch Sign/On Mode. The JCL can be accessed through CA Roscoe IE, CA Vollie, TSO or any other batch job submission method and submitted for
CA Dataquery™ for CA Datacom®
signon and execution. Sign/On mode allows a user who cannot access a CICS monitor to submit batch
CA Dataquery™ for CA Datacom®
jobs through CA Roscoe IE or some other job submission method. See Batch Sign/On Management for more information about batch Sign/On.
Prerequisites for Using Batch
CA Dataquery™ for CA Datacom®
To use batch
CA Dataquery™ for CA Datacom®
, you must:
  1. Tailor the active System Option Table (DQOPTLST) for batch job submission. The following are the DQOPTLST parameters that impact batch job submission:
    • DQDBID=
    • EXPDEV= (z/VSE only)
    • LINPRTL=
    • LINPRTP=
    • RTIMDQE= (SQL Mode only)
    • RTIMDQW=
    • SEQBUFS=
    • SORTWK= (z/VSE only)
    • SUBEXIT=
    • SXBEXIT=
    • URTPRTY=
  2. After modifying the DQOPTLST macro, reassemble and link edit it.
  3. Place the updated System Option Table into effect in one of the following ways:
    • If the CICS RES count is zero, do a CICS NEWCOPY of DQSYSTBL.
    • If the CICS RES count is not zero, bring down the monitor and bring it back up again.
  4. Check the parameters of the DQW (Work Table). See DQW: Work Table for instructions.
  5. Set up the JCL members. Sample JCL for executing DQBATCH in Sign/On mode in z/OS and z/VSE is included at the end of this chapter.
Installing the Internal Reader
If your users plan to execute queries using EXECUTE with a report destination of system printer or using SUBMIT, you must first install the CAIVPE internal reader.
  • z/VSE
    See the CA CIS for VSE documentation.
  • z/OS
    Use the JES internal reader supplied by IBM for job submission. The statements of the job stream are written to a sequential file. The file is assigned to the JES internal reader with a DD statement. CAIVPE-based products executing in a partition can share a common JES reader. Interleaving of data from different products assigned to the same reader is prevented by the CAIVPE enqueue mechanism.
    For the name of the sequential file under the CICS TP monitor, make an entry in the Destination Control Table (DCT) for the DESTID or use the default. Unless the default is changed during IPC installation, it is IRDR. Following is a sample for making the entry after signing on to CICS:
    1. Verify if the entry is there. If not, go to step 5.
      CEDA VIEW TDQUEUE(IRDR) GROUP(*)
    2. If you need to change an attribute, specify ALTER to the right of the entry and press Enter. Overtype to modify values and press PF3.
    3. Disable and close the TDQUEUE to CICS through:
      CEMT INQUIR TDQUEUE(IRDR)
      If it shows enabled (ENA) and open (OPE(N)), then overtype these two values with the following commands:
      DIS (disabled) CLS (closed)
    4. If IRDR needs to be defined, issue the following commands:
      CEDA DEFINE TDQUEUE(IRDR) GROUP(DQGRP) TYPE(EXTRA) DDNAME(ADRSRB) TYPEFILE(OUTPUT) RECORDSIZE(80) RECORDFORMAT(FIXED) BLOCKFORMAT(UNBLOCKED)
    5. Install the modified definition into CICS through the following command:
      CEDA INSTALL GROUP(DQGRP)
    Make sure there is a DD statement that assigns the file to the internal reader. The DSCNAME keyword in the DFHDCT macro provides the ddname. This entry may already exist as the result of another CA product installation.
Executing Deferred Batch Queries
Online
CA Dataquery™ for CA Datacom®
allows a user on an online system to create a query or dialog, or to select a query or dialog from a directory of queries and dialogs. The user can then use the batch execution facility of an online query to submit that query to execute in the batch mode, either immediately or at a deferred time. Executing a deferred batch query is a two step process. Jobs submitted as deferred batch queries do not run until a separate
CA Dataquery™ for CA Datacom®
Batch job with a DEFER control statement executes them.
How a Deferred Batch Query Works
When you request deferred batch execution, an entry is made in a queue in the DQF table, but no job is submitted. The date and time your request was submitted establishes its place in the queue of jobs that are eligible to be run. When you later submit a
CA Dataquery™ for CA Datacom®
batch job with a DEFER input statement,
CA Dataquery™ for CA Datacom®
responds to the DEFER by retrieving and sequentially executing all deferred queries in the queue of eligible jobs.
CA Dataquery™ for CA Datacom®
stores the queue of deferred batch queries in the DQF table.
Considerations for the System Programmer
Because all the deferred queries in the queue can be sequentially executed by the submission of a single
CA Dataquery™ for CA Datacom®
Batch job that includes a DEFER statement, make certain that the JCL contains everything the queued queries need, for example DD statements for external SORT work areas for system SORT, EXPORT DD statements, and sufficient region/partition size.
Also remember to take into consideration that when you use the DQWFINIT utility to reinitialize the DQF, the queue of deferred queries is destroyed.
If your users plan to defer execution of batch queries, you must:
  • Assess when the best time to run the deferred queries is: consider the needs of your users and your system
  • If you set up a regular schedule for executing deferred batch queries, communicate the schedule to your
    CA Dataquery™ for CA Datacom®
    Administrator
  • Submit the jobs at the appropriate time
See Executing Deferred Batch Queries for more information.
Preparing for Batch Export Function Use
The
CA Dataquery™ for CA Datacom®
batch export function allows the user to export the columns and keys named in the PRINT or DISPLAY statement of the query to an output table in the order specified in the query. This exported data is then available for use in user-written programs.
Types of Export Files
CA Dataquery™ for CA Datacom®
places the requested exported data in a sequential output file. Thus, you must allocate a data set for the exported data. There are two different types of export output file:
  • For export as comma-separated values, the output data set must be a sequential file with variable-length rows and blocked format with a block size of 4096 bytes. The maximum length of any data row is 4088.
    If the user executes more than one comma-separated value EXPORT per any execution of DQBATCH,
    CA Dataquery™ for CA Datacom®
    writes all of the output sets to the same output sequential data set.
    The exported data set can be downloaded to a PC, since it is in PC file format (CSV).
  • For export of fixed-length records, the output data set must be a sequential file with a record length equal to that of the exported rows.
    The user may not execute more than one fixed-length EXPORT per any execution of DQBATCH. If a second fixed-length EXPORT is performed within a single execution of DQBATCH,
    CA Dataquery™ for CA Datacom®
    overwrites the data from the first EXPORT.
z/VSE Requirements
In a z/VSE environment, the System Option Table EXPDEV= parameter specifies the default device for exported data. This default can be overridden for nondeferred jobs at submit time when the system prompts the user for the device. If the exported files will be stored on disk, you should assign some specific space for that purpose. For more information, see Accessing Exported Data.
Sample JCL for Batch Sign/On Mode
When using
CA Dataquery™ for CA Datacom®
through the Sign/On mode, all of the input to batch
CA Dataquery™ for CA Datacom®
is made through the use of SYSIN or SYSIPT control statements for z/OS and z/VSE respectively. Provide individual control statements for each
CA Dataquery™ for CA Datacom®
command, with only one command per statement. Examples follow:
Sample z/OS JCL
//jobname
See
// EXEC PGM=DQBATCH //STEPLIB
See
//SYSUDUMP DD SYSOUT=* //SYSPRINT DD SYSOUT=* Print Output //SNAPER DD SYSOUT=* //USRPRINT DD SYSOUT=* //SYSIN DD * Command input SIGN/ON dq-user-id PASSWORD ppppppppp EXEC sample-query /* //
Sample z/VSE JCL
* $$ JOB ...
See
* $$ LST ... // JOB name // EXEC PROC=procname
Whether you use PROCs or LIBDEFs, see
// EXEC DQBATCH SIGN/ON dq-user-id PASSWORD ppppppppp EXEC sample-query /* /& * $$ EOJ