The DB2 Interface › JARSDB21: Debit Record Creation › JARSDB21 Execution Description

JARSDB21 Execution Description

The control statements used in JARSDB21 are described below. Complete descriptions of all CA JARS Wizard control statements can be found in the CA JARS Wizard Reference Guide.

PARAMETER

The PARAMETER control statement specifies options for a CA JARS Wizard run.

XREF

Creates a cross-reference of the data fields used in the run and the statements they are found in. This cross-reference listing is printed in addition to the control statements and the report for the run.

NOPC

Suppresses the CA JARS Wizard error handling routine.

INPUT

INPUT statements are used to identify the CA JARS Wizard glossary and/or the input files for the run. In JARSDB21 two INPUT statements are given:

1. The first INPUT statement lists the CAWGJRD2 glossary as the glossary for the primary input file for the run.
2. The second INPUT statement describes the secondary input file. Secondary files are only used when file matching is to be performed. KEY = 2CC1-8 defines the matching key field for the secondary file. Here, the first eight positions of each record are the matching key. MATCH = USER/ID designates the user ID field of the primary input file as its matching key field.

   TABLE indicates that the secondary input file is a table file to be read completely at the start of the run. Therefore, the entire file is available for searching during the run. The field in positions 10 through 25 of the secondary file contains the account information.

   The notation 2CC10-25 serves two purposes. It:

   • identifies the location of a data field in the secondary file.
   • serves as a name for the field.

DEFINE

Ten DEFINE statements are given in JARSDB21. Each defines a field for the run. The first nine DEFINE statements define fields for the debit record. All of the defined fields are initialized each time a new record is processed.

1. OFILL1: One-byte reserved field, initialized as a blank.
2. ODEBIT: Eight-byte field, initialized as DEBIT. This field identifies the statement as a DEBIT statement.
3. OCPUID: One-byte field, initialized as a blank, and used to identify the CPU.
4. OUSERID: Eight-byte field, initialized as blanks, and used for user identification.
5. ODATE: Six-byte field, initialized as blanks, and used for the date (YYMMDD).
6. OJOB: Eight-byte field, initialized as blanks, and used for the job name.
7. OTIME: Six-byte field, initialized as blanks, and used for the time (HHMMSS).
8. OPROGRAMMER: 20-byte field, initialized as blanks, and identifying the programmer.
9. ODEBITAMT: Six-byte field, initialized as zero, and used for the debit amount.
10. IOREQT: Six-byte field used to hold the sum of the READ/SYNC and READ/PREF counts for all buffer pools.

COMPUTE

Four COMPUTE statements are executed in JARSDB21.

The first COMPUTE statement evaluates the file matching between the primary input file and the secondary file. It also defines a new field OACCT (16 bytes) and assigns a value to it based on the results of file matching. If a match occurs on the user ID of a primary input file record and a secondary input file record, OACCT is assigned the value of the account information in positions 10 to 25 of the secondary file. Otherwise, OACCT is assigned a value of UNKNOWN.

Notice the (P) suffix code appended to the first COMPUTE statement. This code indicates that the COMPUTE should take place before the primary input file records are sorted. This is necessary because the SORT occurs on the OACCT field.

The remaining three COMPUTE statements simply assign values to fields: OUSERID, IOREQT, and ODEBITAMT. OUSERID is assigned the value of the user ID in the primary input record. IOREQT and ODEBITAMT are calculated from other fields in the primary input record.

SORT

The SORT statement identifies the sequence in which the input records should be sorted prior to processing. Here the sort is performed on OACCT (the account information). Note that the OACCT field is created and assigned a value in the COMPUTE(P) statement before the SORT.

BREAK

BREAK statements define logical groups of records. Here data is split into groups by OACCT. Records with the same account information are grouped together.

A SORT statement must be included in a CA JARS Wizard run when a BREAK statement is used. The fields specified in the BREAK statement must be included in the SORT statement and must be specified in the same order as the SORT statement.

HEADING

HEADING specifies a title for the report. Here the title for the report (created in addition to the output file) is: TOTAL DB2 CHARGES BY ACCOUNT.

LIST(SUM)

A summary listing is requested along with the output file. Each line of the summary listing lists debit information for a different account. The LIST(SUM) statement identifies the data fields to be summarized and printed. This data includes the:

• account identifier (information)
• calculated total charge for the account
• total CPU time used by the account
• total number of read requests used by the account
• number of DB2 accounting records for the account

OUTPUT(SUM)

One summary debit record is produced for each unique account. All records are written to the file identified by ddname CAIJWOP. The OUTPUT statement lists the fields to be summarized and included in each debit record.