Step 3. Process type 89 records by the usage report program

To meet the requirement to report product usage, you must use the usage report program, IFAURP, to process all the SMF type 89 records collected for the processor's or parallel sysplex's measurement period. The type 89 records for all the OS/390® and z/OS® images (LPARs) are required for each participating processor or parallel sysplex. Note that you must not alter type 89 records before you run the usage report program to process them. There is no requirement, however, to run IFAURP on the processor on which the type 89 records were collected.

Once IFAURP processes these records, you may discard them, because IFAURP saves the usage information contained on these records in a relatively small history file. Even so, IBM® recommends that the installation retain these records, perhaps on tape, for at least a year and a half to be able to process the records if necessary. A single tape/cartridge should easily accommodate all the type 89 records generated by all the OS/390 and z/OS images in a large installation over the course of a year, when the records have a BLKSIZE of 32,760.

IFAURP has been designed to accommodate the usage data collected from any mix of processor configurations. A single execution of IFAURP can handle any combination of processor configurations. A “processor configuration” can be a single OS/390 and z/OS LPAR or all the OS/390 and z/OS images for all the processors in the installation's data center, including those processors that are a part of parallel sysplexes, whenever they all share a common IBM customer number. IFAURP can also accommodate a wide variety of processing and scheduling requirements, which are often highly installation dependent. For instance, you can run IFAURP to process SMF data sets daily, weekly, monthly, or more or less often.

IFAURP recognizes duplicate SMF records, which often occur as the result of procedural errors. IFAURP bypasses all duplicate records, regardless of whether they are recognized as duplicates during a single execution of IFAURP or across multiple executions of IFAURP. The latter case might occur when unique type 89 records are processed on one execution of IFAURP, during which the appropriate usage data is placed in the history file, followed by another execution of IFAURP with the same SMF input data set. In this case, IFAURP recognizes the records on the input data set as duplicates of the data already stored in the history file.

Figure 1 shows IFAURP's general SMF record flow as three separate job steps. Basic processing consists of passing only the type 89 records to the SORT for sequencing purposes, then passing both the sorted type 89 records and the latest history file to IFAURP.

Figure 1. General data flow required in usage reporting

In the first step, the general purpose SMF dump utility, IFASMFDP creates an intermediate data set containing only type 89 records. This utility program can also select SMF records based on additional criteria, if necessary, such as system name (as defined by the SID parameter) and/or the date and time that the records where originally written. Installations that already save type 89s on data sets dedicated to that record type can bypass this first step. Installations can also bypass this first step, if their system SORT can select records based on the content of specific fields. DFSORT, for instance, can eliminate the need for the IFASMFDP step by selecting only the type 89 SMF records for sort processing when the following additional SORT control statement is supplied:

  INCLUDE COND=(6,1,BI,EQ,X'59')

Failure to restrict SORT processing to type 89 records results in unnecessary sort processing time and sorting resources.

Note: The IFASMFDP utility adds a type 2 and 3 SMF record to the output data set, in addition to the SMF type 89 record.

Figure 2 and Figure 3shows sample JCL for the general case (Figure 1). This JCL is available in SYS1.SAMPLIB member IFAUJCL. The JCL collects type 89 subtype 1 and subtype 2 records but generates only measured usage reports. See Invoking IFAURP for information about how to change the JCL to generate the product registration report.

If your installation has multiple processors, you must decide how many processors to associate with a specific set of old/new history files. You can associate a single processor or all your installation's processors with a single set of old/new history files. There are only three history file processing requirements. These are:

All the OS/390 and z/OS images (logical partitions) on a processor must use the same set of old/new history files.
All the processors in a parallel sysplex must use the same set of old/new history files.
All processors in the same set of old/new history files must share a common IBM customer number. IBM recommends that you use the same set of old/new history files for all processors that share a common IBM customer number. This simplifies processor movement into or out of parallel sysplexes.

Figure 2. Sample JCL for the general usage report function (part 1)

//IFAURP    JOB   'accounting information'
//*---------------------------------------------------------------------
//*  CREATE A TEMP FILE WITH ONLY SMF 89 RECORDS
//*---------------------------------------------------------------------
//IFASMFDP EXEC PGM=IFASMFDP
//SYSPRINT DD  SYSOUT=*
//DUMPIN1  DD  DSN=CUSTOMER.SYSTEM1.D94227.DISP=SHR
//DUMPIN2  DD  DSN=CUSTOMER.SYSTEM2.D94227.DISP=SHR
//DUMPOUT  DD  DSN=&&SMF89,DISP=(NEW,PASS),
//             UNIT=SYSDA,SPACE=....
//SYSIN    DD  *
       INDD(DUMPIN1,OPTIONS(DUMP))
       INDD(DUMPIN2,OPTIONS(DUMP))
       OUTDD(DUMPOUT,TYPE(89))
/*
//*---------------------------------------------------------------------
//*  SORT THE SMF 89 RECORDS INTO ASCENDING ORDER
//*---------------------------------------------------------------------
//SORT     EXEC PGM=SORT
//SYSOUT   DD  SYSOUT=*
//SORTWK01 DD  UNIT=SYSDA,SPACE=(CYL,(1),RLSE)
//SORTWK02 DD  UNIT=SYSDA,SPACE=(CYL,(1),RLSE)
//SORTWK03 DD  UNIT=SYSDA,SPACE=(CYL,(1),RLSE)
//SORTIN   DD  DSN=&&SMF89,DISP=(OLD,DELETE)
//SORTOUT  DD  DSN=&&SORT89,DISP=(NEW,PASS),UNIT=SYSDA,
//             
DCB=(RECFM=VBS,LRECL=32756,BLKSIZE=4096),
//             SPACE=....
//SYSIN    DD  *
       OPTION VLSHRT
       SORT FIELDS=(5,250,CH,A)
/*

Figure 3. Sample JCL for the general usage report function (part 2)

//*---------------------------------------------------------------------
//*  PROCESS 89 RECORDS AND GENERATE USAGE REPORTS
//*---------------------------------------------------------------------
//IFAURP   EXEC PGM=IFAURP,REGION=0M
//STEPLIB  DD  DSN=SYS1.SIFALIB,DISP=SHR
//         DD  DSN=vendor.lib,DISP=SHR  (OPTIONAL - PROVIDED BY VENDOR)
//SYSMSGS  DD  SYSOUT=*
//SYSUDUMP DD  SYSOUT=*
//SYSPRINT DD  SYSOUT=*
//vendor   DD  SYSOUT=*                 (OPTIONAL - FOR vendor's REPORTS)
//SMFDATA  DD  DSN=&&SORT89,DISP=(OLD,DELETE)
//SYSHIN   DD  DSN=MULC.HISTORY.#1234567(0),DISP=OLD
//SYSHOUT  DD  DSN=MULC.HISTORY.#1234567(+1),DISP=(NEW,CATLG,DELETE),
//             DCB=(RECFM=VBS,LRECL=32760,BLKSIZE=16384),
//             UNIT=SYSDA,SPACE=...
//SYSIN    DD  *
*
* Customer name and address
*
  CUSTOMER(NAME('Acme Tulle and Dye Company')
           ADDRESS('155 Main Street',
                   'New London, CT 05512')
           CONTACT('Fred Tulle')
           PHONE('(203) 000-1212 ex 54'))
*
* Vendor name and address
* (sample only - IBM rep will supply to each customer)
*
  VENDOR(PRODOWNER('IBM CORP')
         NAME('IBM Branch Office')
         ADDRESS('1133 Westchester Avenue',
                 'Major City, Sample State  10604',
                 'FAX: 1-800-000-1212  ATTN: Measured Usage Pricing')
         CODE(1234567))
*
* Parallel sysplex definition and products
*
  SYSPLEX(ID(SYSPLEX1)
          PLEXDATE(19950328)
          PROCESSOR ((9021,962,33333),(9672,RX5,00166))
          PRODUCT (PRODOWNER('IBM CORP')
                   PRODNAME('CICS')
                   START(19941101,ALIGN(1)))
          PRODUCT (PRODOWNER('IBM CORP')
                   PRODNAME('IMS TM')
                   START(19941101)))  *
* Processor definition and products
*
  PROCESSOR((9021,952,01111)
            PRODUCT (PRODOWNER('IBM CORP')
                     PRODNAME('CICS')
                     START(19941103))
            PRODUCT (PRODOWNER('IBM CORP')
                     PRODNAME('TSO/E')
                     START(19941103))
            PRODUCT (PRODOWNER('IBM CORP')
                     PRODNAME('IMS TM')
                     START(19941103)))
/*

Figure 4 shows a separate set of history files for each of the reporting entities in the data center, processor 01111 and a parallel sysplex, SYSPLEX1. Neither of the history files can contain fewer LPARs or systems than those shown in this figure.

Figure 4. Example of an installation using a separate file for each reporting entity

In contrast, Figure 5 shows a single set of history files for the entire data center. IFAURP reports the same on all the processor configurations sharing a common IBM customer number, regardless of whether you choose to maintain a separate history file for each reporting entity, or choose to maintain a single history file for the entire data center.

Note: IBM recommends installations use a single set of history files for their processors that share a common IBM customer number to simplify processor movement into or out of parallel sysplexes.

A complete description of the files, control statements, and reports generated by IFAURP appears in Reporting product information.

Figure 5. Example of an installation using a single history file for all reporting entities (recommended)