This chapter describes accounting and chargeback considerations for JES3 and JES2 environments. This information might be valuable to Information Technology (IT) departments and IT management that account for and recover cost, for the use of mainframe resources. This chapter does not go into detail about managing SMF records, nor does it discuss IBM or ISV products that perform accounting or chargeback functions. Basic information is presented about what SMF record types are created by JES2 or JES3 and the differences between the two environments. Topics included in this chapter are:

 

Technology continues to develop, grow and evolve, resulting in increased functionality and capability, which many times translates into more complex IT systems. This is especially true in today’s business climate composed of mostly composite applications, where multitier architectures are common. Over the years, businesses have become very reliant on IT solutions to run their business entities.

IT solutions have greatly increased productivity over time contributing to a higher output of goods and services. This has resulted in larger IT costs due to increased complexity and volume of new integrated application systems. These costs include the operations, software, infrastructure, and labor, among others that contribute to increasing business costs.

Today’s IT management has an increased focus on the total cost of ownership (TCO) of IT solutions. In managing cost structures, it becomes very important to use the most accurate data possible to make informed business decisions. One way to manage these costs is for an installation to institute a chargeback model. In this manner, appropriate charges for allocation of resources can be more equitably distributed back to those business areas.

In today’s economic times, there is added focus on IT budgets. IT capacity and performance area roles have been or new departments created entirely within IT organizations to support and manage costs and budgets. A large area of focus within these new departments is on the accounting and chargeback process to recover costs.

The primary function of the chargeback process is to recover the costs in aggregate of the investments made in the overall IT infrastructure and services. The chargeback process typically attempts to fairly distribute the cost of providing the corporate IT service across users of that service based on CPU usage or some metric.

Some areas to be considered in relation to chargeback include:

Examples are CPU, print, storage, and use of off-site backups. Whatever metrics you use must be consistent across technology changes and as simple as possible. For example, if you charge for each I/O, a simple change in blocksize for a busy data set might result in a significant change in the cost of the associated jobs. Therefore, try to select metrics that will not be easily affected by trivial changes.

For example, services that require a response time guarantee or higher priority for batch work might be charged a premium for that added level of service.

Usage information is typically stored in SMF records. The particular records that you use will depend on which metrics you base your chargeback algorithms on.

There are a number of products available from IBM and other vendors that understand the layout of the most commonly used SMF records and that can form the basis of your chargeback application. Typically, installations use third-party products to format and report this type of data. For more information about accounting and chargeback details, see Accounting and Chargeback with Tivoli Decision Support for OS/390, SG24-6044.

Both JES systems use SMF records to collect and record activity on job-related functions. Most SMF record types are unaffected by which flavor of JES you run. However, there are some record types that are created by JES2 or JES3, and some record types where the type of JES that you are running can have an impact on specific fields. The SMF records that are sensitive to the JES you are running and that are likely to be of interest from a chargeback perspective are:

There are other SMF record types that are created by JES2 or JES3, mainly related to NJE. However, those records are not related to chargeback so we will not cover them here. If you are interested in those record types, search z/OS MVS System Management Facilities (SMF), SA22-7630, for instances of JES2 or JES3.

It is also possible that you might have JES3 user exits that create SMF records. If that is the case, you need to determine how you will handle that as part of your migration plan.

Both JES3 and JES2 create SMF Type 6 records for output writer processing. This record identifies the output by SYSOUT class, form number, and identifies the job according to job log identification, JES2 assigned job number, and user identification. However, there are slight differences in the record for JES2 compared to JES3.

If an external or user-supplied writer is used, SMF will produce an incomplete Type 6 record. This happens only when the external writer directs output to a printer or punch. Also, if the external writer directs output to tape or disk, SMF does not produce a Type 6 either. The incomplete Type 6 record differs the JES2 Type 6 record as follows:

The JES3 Output Service creates an SMF Type 6 (JES3 Output Writer) record for each data set processed. One Type 6 record is written for each data set section within an output scheduler element (OSE). If a printer is running under the control of a functional subsystem (FSS), a Type 6 record is written on the system containing the FSS address space that processed the data set.

The JES2 writer creates a Type 6 record when processing is completed for a job output element (JOE), or when there is a change in certain information describing SYSOUT data sets processed in the same JOE. JES2 also creates a Type 6 record for SYSOUT data sets. If a printer is running under the control of an FSS, a Type 6 record is created. This record is also created for spin data sets. This behavior can be adjusted on a job class basis using JES2 exit 21.

Both JESs create the following information in the Type 6 record:

For specific information about the difference between the JES3 Type 6 records and the JES2 Type 6 record, refer to z/OS MVS System Management Facilities (SMF), SA22-7630.

This record type is written whenever a job or SYSOUT is written to or received from a JES2 offload data set. This record identifies the name, time, and date for each job that has been transmitted or received. It includes specific information about jobs in a record subtype. For jobs not yet run, it reports job-related information such as job class and system affinity in both the job selection criteria section and in the system affinity section. For jobs that have run, it reports information about SYSOUT data sets such as output group ID and forms name in a SYSOUT selection criteria section and the job selection criteria section.

There is no equivalent record for JES3.

A Type 25 record is written for each job that completed JES3 converter/interpreter (C/I) processing. One Type 25 record is written for each job, whether the job contains DD statements or not. A separate Type 25 record is written for each job that uses a private catalog or each Main Device Scheduling (MDS) dynamic unallocation request.

This record also contains allocation-related information such as the number of tape and disk volumes fetched and mounted, and the time of the JES3 device verification. The job log identification is composed of the job name, time, and date that the reader recognized the JOB card of the job. This does not have an equivalent in JES2.

The SMF Type 26 record is created by both JES3 and JES2 and contains information about job purge processing. Note that the record mapping for the Type 26 record is slightly different for JES2 and JES3.

A Type 26 record is created by JES3 at job purge after all SYSOUT for the job has been processed. This record identifies the job by job log identification, JES3 assigned job number, and the programmer’s name.

The JES3 Type 26 record contains the following information:

After all SYSOUT processing is complete, JES2 calls SMF exit IEFUJP. This allows an installation to decide whether to write a Type 26 record at job purge. Similarly to JES3, this record identifies a job by job log identification, JES2 assigned job number, and programmer’s name. JES2 can be configured to not create this record type.

Record type 26 in JES2 contains operating information such as:

For specific information about the layout of the two SMF records, refer to z/OS MVS System Management Facilities (SMF), SA22-7630.

The Type 30 SMF record is the SMF record type that is most commonly used by accounting and chargeback programs. This record consolidates data that is found in other type records. It consolidates data that is found in record types 4, 5, 20, 34, 35, and 40, and it provides additional information. The Type 30 is the recommended record for chargeback and accounting because the record types that it replaces are generally not being updated with new measurement data.

Most of the fields in the type 30 record do not come from JES3 or JES2 directly. Note that the type 30 record has many subtypes; it is not the intent to cover them all here. Also, information might differ by subtype. Examples of subtype data recorded can include:

There are a few Type 30 field differences between JES3 and JES2. They are as follows:

For more information about the SMF record types, refer to z/OS MVS System Management Facilities (SMF), SA22-7630.

These records are written when either JES is started. For JES3, a Type 43 record is written during JES3 and the converter/interpreter functional subsystem (C/I FSS) initialization. This contains an indicator for the type of JES3 Start, JES3 initialization deck origin type, and contents, and JES3 procedure name.

For JES3, a Type 45 record is written when JES3 and C/I FSS are terminated.

For JES2, a Type 45 record is written when a $PJES2 command (to withdraw JES2 form the system) is issued.

A Type 59 record is written when MVS/Bulk Data Transfer (MVS/BDT) completes a file-to-file transmission over an SNA connection. When the connection is BSC, BDT does not write the record: in that case, JES3 writes a Type 57 record instead. MVS/BDT writes Type 59 records from the global node where the transaction is queued and produces a record regardless of whether the transmission was successful or not.

This record type does not exist for JES2.

Many installations use the accounting information on the job accounting string on the //JOB card. The JOB card can contain two positional parameters (see Table 16-1) as well as keyword parameters. The positional parameters are accounting and programmer name and must be coded before any keyword parameters. Within the positional parameters, the accounting information is the first one.

Where account-number is installation-defined accounting information and accounting-information is more installation-defined accounting information. For example, department or room number.

There are nine different subtypes of the accounting-information parameter. They are as follows:

Here is an example of the positional nature of the accounting information.

This statement shows a JES2 accounting information parameter where programmer’s accounting number is AB01, room number is PL105, estimated job time is 15 minutes, and three copies are requested.

For more information, refer to z/OS V1R13.0 MVS JCL Reference, SA22-7597.

In addition, JOB accounting information can be overridden in JES2 by the /*NETACCT statement and in JES3 by the //*NETACCT. Both of which are used to specify an account number for a network job.

Use the ACCTFLD= parameter on the JOBDEF statement to control whether JES2 is to scan the accounting field of the JOB statement. The accounting field is valid if its format matches the format specified for JES2. (For a description of the JES2 format for the accounting field, see the accounting field parameter described in z/OS MVS JCL Reference, SA22-7597.)

You can supply an Exit 3 or Exit 53 installation exit routine to scan and change the accounting field in the JOB statement. See z/OS JES2 Installation Exits, SA22-7534 for information about Exit 3 or Exit 53 and for the exit routine’s relationship to the ACCTFLD= parameter on the JOBDEF initialization statement.

The JES2 NETACCT initialization statement determines the correspondence between the network account numbers and the local account numbers for a node. JES2 uses the parameters on the NETACCT statement to build the network account table used by input processing, the job and SYSOUT transmitters, and the job and SYSOUT receivers.

JES2 recognizes the following network accounting control statement:

where vvvvvvvv is a 1-byte to 8-byte alphanumeric character network account identifier. When the input service processor encounters this statement, it inserts the network account identifier in the job’s job header and looks up the number in the network account table built at JES2 initialization to find an associated local account number. If a local account number is found, JES2 will move the number into the job’s job control table, overriding any account number present. For more information, see z/OS JES2 Initialization and Tuning Guide, SA22-7532.

Most of the accounting information for JES2 and JES3 are similar. One item that to be aware of in terms of accounting and chargeback is the slight differences in where some JES-related processing takes place. This is centered around the fact the two JESs, at an elementary level, function differently.

JES3 is made up of two components, the JES3 Global and Local. In JES3, all processing is serialized through the JES3 Global before any execution takes place. Whereas in JES2, this concept does not exist and set up is done differently in JES2.

The JES3 Global is where the bulk of the work is done, such as all the converter/interpreter (C/I) setup and might then run the job in JES3 Local on another system. Whereas in JES2, the converter function is completed in the JES2 address space and interpretation is completed in the Users address space when it is selected for execution. So now, some setup that used to be in the JES2 MAS and still is in the JES3 Global can cause a shift of CPU to be used in the Users address space. Overall, this is more efficient processing. Since most of the overhead set up in JES3 is done on the Global, the total CPU time associated with the job might only reflect what was in the Local, thus skewing the CPU results.

Refer to 13.1, “Performance of JES2 compared to JES3” on page 156 for more details about this.

The difference in accounting stems from the fact that most installations probably absorb the costs that are associated with setup processing in JES3 Global. This means, currently, the CPU cost isn’t counted toward the business application area running the job. In JES2, since this does not exist, there might be a slightly higher cost associated with running the same job in JES2. In essence, the business unit is being fairly billed, since the costs that were taken in with JES3 Global processing should have been federated to the business units anyway. This is something to review and keep in mind as your installation migration effort reaches a point of testing where there is enough volume in the system to analyze the differences. As part of a migration plan, this type of information must be communicated to business areas so they can make adjustments.

Use information that you gathered at your installation that is based on the activity in this chapter to be stored for later use. In particular, review 5.2, “Discovery analysis process” on page 81 about using this information as part of that process.