|
|
|
In this example, the same data is used, but the following features of the report writer are implemented:
Charges are calculated for each job, based on CPU time used. Depending on how long a job awaited execution, different rates are applied.
Using the grouping feature, this example assigns different charge rates for jobs based on reader queue time distribution.
A summary line is generated for each group of jobs with the same rate applied, and a special description prints on that summary line.
The additional control statements needed to perform this task are:
This statement defines to CA JARS which field is to be grouped on. This is a conditional selection/rejection process equal to an IF-condition check in programming and works with the GROUPC statements to test the contents of a field. In this example, we reject all TSO records and test the reader queue time field of all other records.
GROUPC statements define conditions of records by setting a value limit on the field tested, specified in the GROUP statement and in this example, assigns a unique CPU ID to each record based on the condition met. The conditions are spans of reader queue time.
This statement is used to give a personalized description to the element sorted on.
A RATE statement causes a charge to be calculated for each job or job-step record based on the rates supplied. Each rate to be applied requires a separate RATE statement. The RATE statements are distinguished by unique CPU IDs, a field that is also carried in the job and job-step records. It is the CPU ID that causes the correct rate application to the proper records.
Before proceeding, please read about these control statements in Chapter 4.
The SORT statement is changed to add CPU ID as the major sort field, and to summarize on it. So the order of this report is job name within CPU ID.
┌───────── causes our descriptions to print as
│ headers for each control break
position 1 ▼ 2 3
1........0.........0.........0...
2SORT 00101 2101608
▲ ▲ causes a summary line to be generated
│ └──────────── every time CPU ID changes
└── the major sort is CPU ID - refer to the Basic
Accounting Table for field positions
Additional output data elements are necessary to see the effects of these features on the report. The DISPLAY statement includes the following data elements:
|
Name |
Output DE ID |
|---|---|
|
Description Field |
02 |
|
Job Name |
04 |
|
Number of Jobs |
14 |
|
CPU Time |
66 |
|
Reader Queue Time |
62 |
|
Processor Time |
29 |
|
Processor Charge |
44 |
position 1 2 3 8
1........0.........0.........0...... .....0
2DISPLAY 002204214266262529244
Refer to the Output Data Elements Table. Remember the format is ndd, where n is the number of leading spaces and dd is the Output Data Element ID (DE ID).
The GROUP statement tells CA JARS what field(s) to use when the program performs the conditional logic. In this example, jobs are charged different rates based on how long they have been in the reader queue, so the field to be grouped on is reader queue time. Additionally, all TSO records are rejected, so we must test the processing ID.
The GROUP statement should be coded as follows:
position 1 2 3 8
1........0.........0.........0... ...0
2GROUP 0281 R1956
▲ ▲
└─────┴─── here we are rejecting TSO records for this
report and then performing grouping on reader
queue time. Refer to the fields in the Basic
Accounting Table to code this statement.
For this example, the groups are:
0 seconds - 30 seconds
30 seconds - 2 minutes
over - 2 minutes
Each group must be assigned a unique CPU ID. This actually places the specified CPU ID into each record that has a reader queue time within the specified range. This is necessary because we want to charge a different rate for each of these ranges in reader queue time. You will see that each rate is specified on a unique RATE statement, distinguished by CPU ID. For every record, a charge is calculated based on a RATE statement that contains a CPU ID that matches the CPU ID in the record.
To define each group, GROUPC statements are necessary:
position 1 2 3 4 8
1........0.........0.........0.........0... ...0
2GROUPC 1T
▲▲
│└─────────────── Records with a processing ID of T are rejected
│ TSO records have a processing ID T.
│
└──────────────── Match to the 1st field on the GROUP statement.
2GROUPC 2000000 000030 A
2GROUPC 2000031 000200 B
2GROUPC 2000201 999999 C
▲▲ ▲
│└────────┴────── Because the field we are grouping on is
│ in the format hhmmss and we are grouping
│ on all 6 positions, the limit of the
│ fields on the GROUPC statements must be
│ in the same format.
│
└──────────────── Match to the 2nd field on the GROUP statement.
A RATE statement should be set up for each of the CPU IDs specified in the grouping for this example. The actual rate that is used should not be interpreted as a practical amount to charge in any particular situation, but merely serves to demonstrate the use of a RATE statement.
The RATE statements should be coded as follows:
position 1 2 3 4 5 8
1........0.........0.........0.........0.........0... ...0
2RATE A1000 200
2RATE B1000 100
2RATE C0500 100
▲ ▲ ▲
│ │ └──── TOTAL CPU factor, a percentage amount
│ │ of the CPU time used to be charged for.
│ │
│ └──── Basic Processor Rate to be used in calculating the
│ charge. In this case CPU Time x CPU Factor x Basic
│ Processor Rate = Processor Charge.
│
└──────────── CPU ID is to distinguish the different rates
to be applied to job and job-step records with
matching CPU IDs.
In this example, we want to print a special description on the summary line for each CPU ID that could be encountered. The DESCRIPT statement is used to substitute a description for the contents of the sort control field at each control break. The use of DESCRIPT statements can make a report easier to read, especially for people who may not be familiar with the sort fields used to generate the report. Descriptions are displayed on the summary line with DE ID 02 specified on the DISPLAY statement, and can be also displayed at the beginning of each change in sort control if descriptive headers were flagged on the SORT statement.
The DESCRIPT statements necessary to do this should be coded as follows:
position 1 2 3 4 5 8
1........0.........0.........0.........0.........0... ...0
2DESCRIPT1A LESS THAN 30 SEC.
2DESCRIPT1B 30 SEC. - 2 MINUTES
2DESCRIPT1C GREATER THAN 2 MIN.
▲▲
│└── this is the CPU ID for each group
│
└─── this 1 means the description specified is to be associated
with the first sort field on the SORT statement
Starting in position 19, code the desired description, up to 20 characters in length.
The HEADER statement can be changed to indicate the actual report we will generate in this second example.
position 1 2 3 4 5 8 1........0.........0.........0.........0.........0... ...0 2HEADER CHARGES BASED ON READER QUEUE TIME
The last change necessary for this example, is to change the set code in the SELECT statement to a 2, since that is what we have coded in position 1 of all the report control statements for this example.
position 1 2 3 4 5 8 1........0.........0.........0.........0.........0... ...0 SELECT 1 2
The control statements for this example are:
position 1 2 3 4 5 8 1........0.........0.........0.........0.........0... ...0 SELECT 1 2 2HEADER CHARGES BASED ON READER QUEUE TIME 2SORT 00101 2101608 2 1 2DISPLAY 002204214266262529244 2GROUP 0281 R1956 2GROUPC 1T 2GROUPC 2000000 000030 A 2GROUPC 2000031 000200 B 2GROUPC 2000201 999999 C 2RATE A0500 100 2RATE B1000 100 2RATE C1000 200 2DESCRIPT1A LESS THAN 30 SEC. 2DESCRIPT1B 30 SEC. - 2 MINUTES 2DESCRIPT1C GREATER THAN 2 MIN.
Use the same input data and the same JCL job stream as you used for Example 1.
The output report is shown on the following page.
CHARGES BASED ON READER QUEUE TIME BEGIN DATE - 02/05/98 RUN DATE - 02/28/98 END DATE - 02/05/98 PAGE 1 JOB JOB CPU RDR QUE PROCESS PROCESS DESCRIPTION NAME NBR TIME TIME-AVG TIME CHARGE LESS THAN 30 SEC. ASMSCH 6262 00:00:06 00:00:29 .00169 $.85 ASMSCH 7852 00:00:05 00:00:29 .00142 $.72 ASMSCH 7855 00:00:06 00:00:30 .00164 $.83 ASMSCH 7918 00:00:05 00:00:29 .00140 $.71 ASMSCH 7919 00:00:06 00:00:30 .00160 $.81 ASMSCH 7923 00:00:05 00:00:30 .00141 $.71 ASMSCH 8170 00:00:06 00:00:30 .00159 $.80 ASMSCH 8863 00:00:05 00:00:29 .00138 $.70 8 00:00:44 00:00:30 .01213 $6.13 . . . ZAP51 6529 00:00:00 00:00:29 .00013 $.07 ZAP51 7282 00:00:01 00:00:29 .00030 $.15 2 00:00:02 00:00:29 .00043 $.22 LESS THAN 30 SEC. 496 02:37:30 00:00:08 2.62492 $1,315.09 30 SEC. - 2 MINUTES APPDA52 8645 00:01:47 00:00:35 .02980 $29.80 1 00:01:47 00:00:35 .02980 $29.80 ASMS627 8292 00:00:05 00:00:33 .00140 $.71 ASMS627 8906 00:00:05 00:00:31 .00137 $.69 . . . ZAP51 7254 00:00:01 00:00:31 .00030 $.30 1 00:00:01 00:00:31 .00030 $.30 30 SEC. - 2 MINUTES 187 00:45:00 00:00:42 .74996 $422.28 GREATER THAN 2 MIN. RIZUPDT 8150 00:00:04 00:02:11 .00106 $.54 1 00:00:04 00:02:11 .00106 $.54 R42LINK 1258 00:00:30 00:02:05 .00825 $4.43 1 00:00:30 00:02:05 .00825 $4.43 GREATER THAN 2 MIN. 2 00:00:34 00:02:08 .00931 $4.97 686 03:23:04 00:02:58 3.38429 $1,742.34
Each group of data is labeled with a descriptive header, which also is displayed on the summary line for that group. This is a job-level detail report, and rates have been applied to each job.
| Copyright © 2012 CA. All rights reserved. |
|