The VM Interface › Reporting Component › Preparing Control Statements

Preparing Control Statements

Control statements are used to tell the Report Writer which reports you want generated, for what time period, and how you want them formatted. They are contained in a file of fixed-length 80-byte records. Each control statement is identified by an eight-character alphanumeric statement type and checked for syntax and discrepancies that might cause errors during the run. If there are errors in the data, the record is flagged and a message is printed indicating the problem area.

Control statements are divided into two groups:

• The first group consists of statements that govern the general aspects of the Report Writer run.
• The second group controls the formatting of individual reports.

The following statements in the first group are required:

• CONFIG statement
• SELECT statement

The following statements in the first group are optional:

• CRITERIA statement
• PARMS statement

The following statements are used to control the format of individual output reports. Since multiple reports can be requested for each run, this group can be composed of many sets of statements, with each set of statements used to define one particular report format. Each set can include a combination of any of the following statement types.

The following statements are required for basic reporting:

• HEADER
• DISPLAY
• SORT

The following statements are optional, grouped by usage.

Computer Billing       Other Format                 Record Grouping
& Budget Control       Customization Features       Feature

BUDGET                 DESCRIPT                     GROUP
CREDIT                 EDIT                         GROUPC
DEBIT                  EXITS
FORMRATE               TITLE
VMRATE

Each report is identified by a set code. This code is used to tie together all control statements relating to a specific report. All the statements for a given set of reports must contain the same set code. The set code consists of any valid EBCDIC character placed in the first position of all statement types, with the exception of the CONFIG, SELECT, CRITERIA and PARMS control statements that never require set codes due to their global nature.

Control statements with blank set codes are referred to as global control statements. The following statement types can have a blank set code that allows them to be included in every report set, but those with an asterisk may be overridden by a corresponding statement type containing a nonblank set code.

  BUDGET
  CREDIT
  DEBIT
  DESCRIPT
* EXITS
  FORMRATE
* TITLE
  VMRATE

It is recommended that you include all sets of control statements when generating reports. Doing so assures that the Report Writer has access to all your user report formats, and relieves you of the necessity of combining the proper sets of control statements for the appropriate run. The SELECT statement is used to indicate which set(s) of statements are required to generate the desired report(s).

Control Statement Coding Conventions

All alphabetic characters entered on control statements are assumed to be uppercase by the editor. In general, all numeric fields are to be right justified and need not be padded with leading zeros, since the Report Writer performs this function as part of its numeric field editing routine. The input control statements are never sorted. Generally, the order of the statements is not important. However, in the case of certain statement types, order may have an effect on report results. Where such order is a consideration, it is noted in the detail description of the affected statement.

Caution Sequence numbers are unacceptable on control statements. The Report Writer interprets them as a function field.

CPU Identification Usage

Five report control statements allow you to specify a 1-byte field called CPU Identification: BUDGET, CREDIT, DEBIT, FORMRATE, and VMRATE. The CPU ID field is simply a 1-byte character field carried in every CA JARS record. When a nonblank character is placed in this field, it tells the Report Writer that the control statement applies only to those records having a matching CPU ID. However, a control statement with a blank CPU ID field applies to all records.

The CPU ID field is used primarily as a user controlled switch to separate different groups of data--it need not have anything to do with actual CPU Identification. There are two ways of setting this field:

• Your User Accounting Table may set the CPU ID based on the VM userid and VM Account Number in the raw VM data.
• The Report Writer Grouping feature, using the GROUP and GROUPC control statements, may set the CPU ID based on any test or series of tests expressible within the bounds of GROUP/GROUPC syntax.

Remember, the CPU ID field is provided as means for you to manipulate and separate data into convenient groups. A typical application is to separate data into groups according to the billing rates you plan to apply. You accomplish this by assigning different CPU IDs for each group on the VMRATE and FORMRATE statements. You can then charge different rates for each group based on their CPU ID.