Sun Mainframe Transaction Processing Software Administrator's Guide

Transaction classes and scheduler process provide a way to manage the different load requirements of a region. If you define transaction classes, the scheduler process is automatically started at region startup. If you do not define any user classes, the region executes as it did in previous releases.

This chapter includes the following topics:

• What Are Transaction Classes?
• Setting Up Transaction Classes
• Deleting Transaction Classes
• Monitoring Transaction Classes

---

What Are Transaction Classes?

A transaction class is a physical group of transactions that have a common priority. The priority of a transaction class can be adjusted by assigning fewer or more transaction processors to the class.

Consider using transaction classes if your application environment has:

• A transaction or set of transactions that are high priority.
• A transaction that needs to be single-threaded because it is long-running or it consumes a lot of CPU time.
• Concurrent batch and online processes.

---

Setting Up Transaction Classes

There are two system transaction classes, KIXDFLT and KIXADMIN. Each system class has one transaction processor assigned by default. You can increase the number of transaction processors, but you may not decrease them below one.

KIXDFLT is the default transaction class.

• All system transactions except CEMT, CINI, and CSMT are assigned to the KIXDFLT class.
• Any user-defined transaction that does not have an explicitly defined transaction class in the PCT is assigned to the KIXDFLT class.
• An administrator can reassign any system transaction(s) from the KIXDFLT class to the KIXADMIN class or a user-defined class.

KIXADMIN is the administrator transaction class.

• The high-priority system transactions CEMT, CINI, and CSMT are assigned to the KIXADMIN class. These transactions will run in any available transaction processor in the event that the assigned transaction processor(s) is busy. If all transaction processors are busy, the transaction is queued.
• The KIXADMIN class has priority within a region. An administrator can assign other transactions to the KIXADMIN class and configure more transaction processors for it, if necessary.
• An administrator can reassign CEMT, CINI, and CSMT to any other class.
• An administrator can assign any transaction to KIXADMIN.

1. Start the region where you want to define transaction classes.

2. Type CTBL on a blank transaction screen to start Table Manager.

3. Press PF5 to display the Extended Tables menu.

4. Press PF1 to open the Transaction Class Table (TXC) shown in FIGURE 4-1.

  FIGURE 4-1 Transaction Class Table (TXC)

5. Press PF4 to add a transaction class.

You can define a maximum of 62 transaction classes.

6. Type values in the following fields:

a. In the Class field, type the name of the transaction class; up to eight characters.

b. If you are using groups, type a group name in the Group field; up to eight characters.

c. In the Max Active field, specify the maximum number of transactions in this class that can be running at one time.

This is also the number of transaction processors that are assigned to this class. Values can be 0 - 1024. If you specify zero, any message arriving for this class will be queued and stay queued until a transaction processor is assigned to the class by CEMT SET TRANCLASS or the EXEC CICS SET TRANCLASS command.

7. When you finish adding transaction classes, press Enter to add the entries to the table.

8. Press PF3 to return to the TXC main screen.

9. Press PF2 to write your changes to disk.

10. Press PF3 twice to return to the Table Manager main menu.

Assigning Transactions to Classes

You assign transactions to classes in the region's PCT. If you do not explicitly assign a class, the transaction is assigned to the KIXDFLT class.

1. On the Table Manager menu, press PF4 to display the Standard Tables menu.

2. Press PF6 to open the PCT.

3. Select a transaction and press PF9 to display the transaction class screen.

  FIGURE 4-2 PCT - Transaction Class Screen

4. Type the name of the class to which to assign the transaction.

You can use the PF7 and PF8 keys to find other transactions to assign.

5. Press Enter to accept the changes and return to the PCT main screen.

6. Press PF2 to write your changes to disk.

7. Press PF3 twice to return to the Table Manager main menu.

---

Deleting Transaction Classes

Before deleting a transaction class, change every entry in the PCT that is assigned to that class. This section contains two procedures: one to use if you only have a few transactions to change, and one to use if you have a large number of transactions to change.

• If you have only a few transactions whose entries must be changed, use the manual procedure in Table Manager.
• If you are deleting a transaction class to which a large number of transactions are assigned, use table's .lst file to make the changes.

1. On the Table Manager menu, press PF4 to display the Standard Tables menu.

2. Press PF6 to open the PCT.

3. For each transaction whose class you are deleting, you must select the transaction and press PF9 to display the transaction class screen.

4. Change the name of the class to which the transaction is assigned.

On the transaction class screen, you can use the PF7 and PF8 keys to find other transactions to change.

5. Press Enter to accept the change(s) and return to the PCT main screen.

6. Press PF2 to write your changes to disk.

7. Press PF3 twice to return to the Table Manager main menu.

8. Press PF5 to display the Extended Tables menu.

9. Press PF1 to open the Transaction Class Table.

  FIGURE 4-3 Deleting a Transaction Class

10. Select the transaction class to delete and press PF5.

When the confirmation prompt is displayed, press Enter to delete the class.

11. Press PF2 to save your changes to disk.

12. Exit Table Manager.

13. You must shut down and restart the region for your changes to take effect.

1. On the Table Manager menu, press PF4 to display the Standard Tables menu.

2. Press PF6 to open the PCT.

3. Export the table by pressing PF12.

4. Using a text editor:

a. Open the pct.lst file.

b. Replace the name of the class you are deleting with the name of the class you want to assign the transactions to.

c. Save the pct.lst file.

5. On the PCT main screen, press PF11 to import the modified pct.lst file.

6. Press PF2 to write your changes to disk.

7. Press PF3 twice to return to the Table Manager main menu.

8. Press PF5 to display the Extended Tables menu.

9. Press PF1 to open the Transaction Class Table.

  FIGURE 4-4 Deleting a Transaction Class

10. Select the transaction class to delete and press PF5.

When the confirmation prompt is displayed, press Enter to delete the class.

11. Press PF2 to save your changes to disk.

12. Exit Table Manager.

13. You must shut down and restart the region for your changes to take effect.

---

Monitoring Transaction Classes

There are three methods for monitoring transaction classes:

• kixdump -St command.
• CEMT INQUIRE transaction.
• Sun MAT. See Chapter 12 for information about the administration tool, and refer to the Sun Mainframe Administration Tool User's Guide for information about monitoring transaction classes.

The kixdump -St command produces a report that shows the following statistics, as well as other statistics that are designed to assist technical support engineers:

The following example shows the output of the kixdump -St command.

11/19/2001 16:07:25 kixdump     :entering version 7.2.0 - 11/13/2001

Transaction Class Statistics:

Class: CLASS_1  queue #: 256  reconfig id: 000000  user area: <c12b6008>

   Max active        : 0001  Current q depth : 000000  Msgs received: 000000004

   Cur max active    : 0001  Maximum q depth : 000000

   Last send time    : Mon Nov 19 16:04:37 2001

   Last receive time : Mon Nov 19 16:04:37 2001

Class: CLASS_4  queue #: 257  reconfig id: 000000  user area: <c12b8100>

   Max active        : 0004  Current q depth : 000000  Msgs received: 000000001

   Cur max active    : 0004  Maximum q depth : 000000

   Last send time    : Mon Nov 19 16:03:32 2001

   Last receive time : Mon Nov 19 16:03:32 2001

Class: CLASS_2  queue #: 258  reconfig id: 000000  user area: <c12c04e0>

   Max active        : 0002  Current q depth : 000006  Msgs received: 000000014

   Cur max active    : 0002  Maximum q depth : 000006

   Last send time    : Mon Nov 19 16:06:03 2001

   Last receive time : Mon Nov 19 16:05:19 2001

Class: KIXADMIN queue #: 259  reconfig id: 000000  user area: <c12c46d0>

   Max active        : 0001  Current q depth : 000000  Msgs received: 000000001

   Cur max active    : 0001  Maximum q depth : 000000

   Last send time    : Mon Nov 19 16:04:05 2001

   Last receive time : Mon Nov 19 16:04:05 2001

Class: KIXDFLT  queue #: 260  reconfig id: 000000  user area: <c12c67c8>

   Max active        : 0001  Current q depth : 000000  Msgs received: 000000019

   Cur max active    : 0002  Maximum q depth : 000000

   Last send time    : Mon Nov 19 16:04:45 2001

   Last receive time : Mon Nov 19 16:04:45 2001

In the sample output, notice that CLASS_2 has two transaction processors assigned (Max active value). It is showing a current queue depth of 6, which indicates that 6 transactions are waiting to execute. All other classes show a current queue depth of 0. To balance performance, determine which transactions are assigned to CLASS_2 and decide whether to move one or more of them to another class or whether to assign more transaction processors to CLASS_2.

The CEMT INQ transaction enables you to view information about one class or all classes.

Execute the following transaction:

CEMT INQ TRANCLASS CLASS_2

Execute the following transaction:

CEMT INQ TRANCLASS ALL

The screen shown in the following figure reports a subset of the kixdump -St information: Class, max active, current max active, number of messages, current queue depth, and maximum queue depth.

  FIGURE 4-5 CEMT INQUIRE TRANCLASS Report

Managing Transaction Classes

If, after configuring the region's transaction classes, you discover that the class-to-transaction processor ratio is not allowing the region to run efficiently, you can dynamically reconfigure the number of transaction processors assigned to a class. The CEMT SET TRANCLASS transaction reassigns transaction processors from one class to another. The examples in this section describe different ways you can manage transaction classes in a region.

Restricting the Use of a Transaction Class

To control when certain transactions are able to run, you can assign zero to the Max active field in the TXC when you create the transaction class, and assign those transactions to that class. At some point during the day, you can "open up" this class and allow the transactions to run.

Be aware that for each transaction class defined to the region, an additional system IPC message queue is created when the region is started. This ensures that the system resource is available if and when the administrator reconfigures the classes and assigns one or more transaction processors to the class. Also, if the Max active field for a class is set to zero and transactions do arrive for that class, they will be queued. If too many of them arrive, the system limits defined for message queues may be reached and the system may experience problems or performance degradation.

Determining When to Reassign Transaction Processors

Use the kixdump -St or CEMT INQ TRANCLASS commands to monitor the current queue depth. Ideally, this number should be zero indicating that there are no transactions waiting to be executed. The maximum queue depth statistic will provide a historical view of the queue and indicate the largest number of transactions that ever waited to be executed. If the current queue depth is always greater than zero, consider adding more transaction processors to the class.

You can easily reconfigure transaction classes to have more or fewer transaction processors using the CEMT SET TRANCLASS command. The EXEC CICS SET TRANCLASS statement can also be used programmatically to reconfigure transaction classes.

Example: Class ABC has 2 transaction processors and class XYZ has 6 transaction processors. Class ABC is experiencing performance problems and CEMT INQ TRANCLASS indicates a current queue depth of 8. You decide to reassign two transaction processors from class XYZ to class ABC. Execute the following transaction:

CEMT SET TRANCLASS ABC MAXACTIVE 2 USE XYZ

If you now view the classes using CEMT INQ TRANCLASS or kixdump -St, the current max active for class ABC should be 4 and the current max active for XYZ should also be 4. Class ABC's current queue depth should be reduced because the 2 additional transaction processors provide additional processing power.

Managing Background Tasks and Batch Jobs

The maximum number of background tasks and batch jobs that can execute are controlled by their settings in the VCT. These settings override any Max active values set in the TXC for classes that contain STARTed transaction IDs or CBCH. Furthermore, assigning other transactions to the same class as STARTed transactions or CBCH can degrade performance because the other transactions may be using the available transaction processors.

Example: In the VCT, the Maximum background tasks field is set to 4 and the Maximum batch jobs field is set to 1. In the TXC, Class2 is defined with 6 transaction processors. In the PCT, you assign 100 transactions to the Class2, some of which are STARTed transactions. During production, some of the STARTed transactions may not be executed promptly because only 4 transaction processors can be used for background tasks and the non-STARTed transactions are using the 6 available transaction processors.

To avoid this type of problem, consider assigning STARTed transactions and CBCH to their own classes, matching the Max active value for each class with the associated setting in the VCT.

Managing the KIXDFLT Transaction Class

By default, all system transactions, except for the three assigned to KIXADMIN, are assigned to the KIXDFLT class. One transaction processor is assigned to KIXDFLT. If no class is specified for a user transaction when it is defined in the PCT, KIXDFLT is assigned to that transaction. Other actions that do not belong to a class, including pressing the Clear key and entering undefined or unknown transactions, are assigned to the KIXDFLT class for execution. Make sure you have enough transaction processors assigned to the KIXDFLT class to avoid performance problems.

When monitoring the KIXDFLT class with kixdump -St or CEMT INQ TRANCLASS, the current max active value may be greater than the max active value, making it appear that KIXDFLT has more transaction processors assigned to it than are specified in the TXC. This discrepancy actually indicates that the number of transaction processors configured in the VCT is greater than the total of the Max Active processors configured for all classes in the TXC, and the "excess" transaction processors were assigned to the KIXDFLT class. Rather than depend on this "cushion," closely monitor the KIXDFLT class and assign transaction processors to it based on region performance data.

API Support

Sun MTP supports the following CICS APIs for transaction classes:

EXEC CICS INQUIRE TRANCLASS(8-char data-value)

EXEC CICS INQUIRE TRANSACTION(4-char data-value)

EXEC CICS SET TRANCLASS(8-char data-value)

Refer to the Sun Mainframe Transaction Processing Software Developer's Guide for descriptions of the supported options.

Sun Mainframe Transaction Processing Software Administrator's Guide

816-5327-11

Copyright © 2004, Sun Microsystems, Inc. All rights reserved.