Utilizing Resources Effectively › Setting Priority in the Operating System and CA Datacom/DB

Setting Priority in the Operating System and CA Datacom/DB

The performance of your system can be affected by setting an appropriate priority in both the operating system and in CA Datacom/DB.

CA Datacom/DB MUF versus CA Datacom CICS Services

If there are many CICS activities involving CA Datacom/DB, assign the CA Datacom/DB MUF a higher priority than CA Datacom CICS Services within your operating system. However, if you have few CICS activities involving CA Datacom/DB, assign the same operating system priority to both the MUF and CA Datacom CICS Services.

Task Priority in CICS

You can assign priority to specific transactions within CICS by using parameters in the TCT, CSD, or Sign-on table. We recommend assigning a priority of 254 for the DBOC and DBUT transactions in the CSD (255 is the highest priority).

Task Priority in CA Datacom/DB

Transactions which use the CA Datacom/DB MUF, are assigned a priority within the MUF. This priority is specified in the URT used with the transaction. A low priority task, which has a resource under exclusive control, could block other users from accessing that resource indefinitely.

Open Transaction Environment (OTE)

You can increase your system performance if your applications are programmed as Threadsafe to operate concurrently in an Open Transaction Environment (OTE) as defined by IBM.

Verify that your programs or modules have the following Threadsafe characteristics:

• The modules must be designated as re-entrant (RENT). Typically RENT modules do not modify anything in the program storage and can be loaded into read only memory.
• The modules either do not modify shared resources or they serialize the use of shared resources by using a serialization technique such as ENQ/DEQ or CS/CDS/CSG and so forth.
• All modules that modify a shared resource must use the same serialization technique.

Perform the following tests to verify that your programs are running concurrently:

• The first test is to take a look at the level one and level two IBM tracing and examine the TCB switching that occurs in a transaction from initiation through termination.

  The examination should answer the following questions:

  1. Where did the application commence execution when called by the TRUE?
  2. Where did the DBNTRY TRUE commence execution when called by the application program?
  3. Was there any TCB switching involved in the course of running a transaction for example, QR to L8 to L9 and back and forth?
  4. Was there a lot of TCB switching because of non-Threadsafe CICS commands or between program calls and returns (because of their Concurrency value in CICS tables)?
  5. Was there supposed to be DB2 calls in the mix and were there any calls made to DB2?
  6. Was TCB switching involved when calling DB2 attachment facility and returning from DB2 to the application or just calling DBNTRY, or both or neither?

     Note: If there are no DB2 calls but the site has DB2 applications mixed with DATACOM calls, select a transaction that has both calls, and examine the TCB switching for DB2 and DATACOM calls in the same manner.

• The second test is to benchmark a fixed number of transactions. For example, run 100,000 or even 500,000 transactions in both environments separately, and then compare the processing time of the two test cases.

  The test environments must be similar in both cases in order for the comparison to be valid. It is best to run each test multiple times and use the average for comparisons.

  Define the application and Datacom as API(CICSAPI) and benchmark it in one set of tests as a base of your measurement. If the application can only run with EXECKEY=USER, then it is probably better to define both the application and the Datacom TRUE as API(CICSAPI). If the application can run with EXECKEY=CICS, then it might be worthwhile to benchmark both with API(OPENAPI) as well and conduct another test with those values in place.

  For more information about selecting CICSAPI or OPENAPI, see Migration Issues in this section.