Reducing potential RECON data set enqueue problems

The following list describes some scenarios that can cause the RECON data set enqueue problems and contain suggestions for avoiding these problems.

• Shared DASD environment scenarios

  Operating in a shared DASD environment, the most common cause of RECON data set enqueue problems is failing to follow the recommendation to catalog each RECON data set in its own ICF catalog on the same volume as the RECON data set.

  If you use serial access and if you catalog each RECON data set in its own ICF catalog on the same volume as the RECON data set and still have problems; examine your GRS, (or equivalent) RESERVE conversion list, to determine how you process SYSIGGV2 and DSPURI01 QNAMEs. A couple of combinations might lead to deadlocks.

• Non-shared DASD environment scenarios
  If you are operating in a non-shared DASD environment and are having problems, this is probably not caused by deadlock but rather by contention and slow performance. Here are a few things to look at in this situation:

  • Minimize the amount of time any job holds the RECON data set.

    One way to minimize that time is to tune the LSR buffer pool DBRC uses when accessing the RECON data sets. There is a CSECT, DSPBUFFS (serial access only), that contains the values used for online and batch. See Buffer Size Specification facility (DSPBUFFS) in IMS Version 15.5 Exit Routines for information about how to zap it and change the values. The defaults might be low for your usage. For parallel access, the IDGSMSxx RLS_MAX_POOL_SIZE definitions should be looked into instead.

  • Analyze the other contents of the volumes where the RECON data set resides. Consider isolating these volumes, to prevent interference from other I/O activity (and vice versa). Consider placing the RECON data sets on high performance cached DASD, or perhaps solid state DASD.

Related reading: See Avoiding RECON data set deadlock situations for serial access mode for more information.