C H A P T E R 4 |
Managing Application Workloads |
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:
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:
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.
KIXADMIN is the administrator transaction class.
To Define Transaction Classes |
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.
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.
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.
To Assign Transactions to a Class |
1. On the Table Manager menu, press PF4 to display the Standard Tables menu.
3. Select a transaction and press PF9 to display the 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.
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.
To Delete Transaction Classes Manually |
1. On the Table Manager menu, press PF4 to display the Standard Tables menu.
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.
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.
13. You must shut down and restart the region for your changes to take effect.
To Delete Transaction Classes Using the .lst File |
1. On the Table Manager menu, press PF4 to display the Standard Tables menu.
3. Export the table by pressing PF12.
b. Replace the name of the class you are deleting with the name of the class you want to assign the transactions to.
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.
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.
13. You must shut down and restart the region for your changes to take effect.
There are three methods for 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.
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.
To Monitor a Specific Transaction Class |
Execute the following transaction:
To Monitor All Transaction Classes |
Execute the following transaction:
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.
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.
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.
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:
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.
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.
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.
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.
Copyright © 2004, Sun Microsystems, Inc. All rights reserved.