Fixing CICS response in combined online/batch Datacom system

Products

• Datacom
• Datacom/DB

Issue/Introduction

There is a problem with CICS transactions taking longer, even though there are fewer transactions each day. It happens about every 30 minutes and response becomes very slow.

Can you tell me if there is something we can look at in the database or index to find a problem?

Environment

Component : Datacom CICS Services

Component : Datacom/DB

Resolution

Concurrent online and batch processing is one of the benefits of using a database product, so there are steps to take to ensure everything is optimized. Here are some things to consider, and this list is not absolute or exhaustive.

1. From an overall perspective, you should ensure that your Datacom MUF is defined to the system at an equal or higher dispatch priority than the CICS region. Consider the MUF as a system-level task nearly like JES. This will ensure your CICS region activity is not affected by waiting on the MUF.
2. Online Datacom activity should be prioritized higher than the batch activity in the MUF. The priority is managed through the URT through the PRTY= parameter on the DBURSTR macro. As a default, all URTs will assume a priority of 7 if not coded, so your CICS URTs should be using a PRTY= that is higher, or your batch URTs should be lower. Some customers go even further, and have different priority levels in batch processing for reporting or utility work that is different from critical-path update work.
3. Consider the size of each unit of work being done by batch programs running during the online processing time. In many overnight batch jobs, the key is to get as much done in a single unit as possible. Therefore, some jobs may not issue intermediate checkpoints, but will run many updates that will be committed at the end of the job. If your daytime batch jobs runs the same way to update lots of records, and hold those records under secondary exclusive control, online transactions that need to update any of those records will wait until the batch job hits a syncpoint or the job ends. This could very easily cause a lag in online processing. Some clients have either used a different program, or a different parm in the batch program to identify work being done during online processing times, so that the batch job issues syncpoints/commits more frequently.
4. Also related to the holding of updated records, if you have batch jobs that are reporting, or read-only jobs, be sure that they are using URTs with UPDATE=NO on the DBURTBL macro. This will prevent them holding records or blocks in an update status unnecessarily.

Additional Information

There is other information available in the Datacom/DB documentation, in the section "Optimizing CA Datacom/DB Performance."

As always, please contact Broadcom support for Datacom if you have further questions.