IXC430E system has stalled XCF group members DFHIR000 and CICS hangs

Technote (troubleshooting)


Problem(Abstract)

Your CICS region is hung and you receive message IXC430E SYSTEM xxxx HAS STALLED XCF GROUP MEMBERS. You do not receive message IXC432I indicating the stall is no longer occurring until about 30 minutes later. When you respond 'D XCF,GROUP' to IXC430E it returns message IXC331I and includes the CICS XCF group *DFHIR0000.

Symptom

Following is the complete IXC331I message:

IXC331I DISPLAY XCF indicates stalls on local system groups
$$TM(2) ARC PLEX0(2) ALTGASSC(1) BBGROUP(1) COFVLFNO(6) *DFHIR000(58)


Cause

In this case, CICS was not being dispatched because the region has a lower dispatching priority than DB2. The following explains how this problem can occur:

  • Two CICS regions are trying to communicate using the cross-system coupling facility (XCF).
  • An XCF message is being routed to another system.
  • XCF is not receiving a response.
The asterisk next to group DFHIR000 in message IXC331I indicates that it has a local member that XCF considers to be stalled. DFHIR000 is the CICS XCF group. In this case, message IXC430E indicates that XCF has called the group exit for CICS on the receiving side and it is not processing the message. In other words, XCF is not getting a response back from the CICS message exit. A response was not returned to XCF for about 30 minutes according to when message IXC432I was received.

This is often a CICS dispatching priority problem. It is typically diagnosed the same way a CICS hang is diagnosed.

Diagnosing the problem

A dump of the CICS address space, the XCF address space, and the XCF dataspaces might be needed. To get this dump, you can enter the following MVS dump command at the time of the hang:


/DUMP COMM=(xxxxx)
/r yy,jobname=(yyyyyyy,XCFAS),DSPNAME=('XCFAS'.*)

where xxxxxx is whatever you would like to call the dump
and yyyyyyyy is the CICS jobname taken from message IEC431I

After you get a dump, you can enter the following IPCS commands to diagnose this problem:

  1. ST SYS to see the time that your system dump is taken. You will need the local time.

  2. VERBX DFHPDxxx 'CSA' where xxx is the release of CICS you are using, to determine the time the CICS region was last dispatched. This can be found at offset x'50' in the CSA (CSATODP). For example, 0556121F. If the CSA time is less than the time the dump was taken this indicates that CICS is not being dispatched by MVS.

  3. VERBX DFHPDxxx 'KE=3' shows the address of QR TCB under the column KE_KTCB in Kernel Domain KE_TASK Summary on the same line with the STATUS of "KTCB QR". You can get the address of the associated MVS TCB (KTCB_ATTACH_TCB_ ADDRESS) from offset x'50' in CICS TS V4.2 and below (or offset x'68' in CICS TS V.51) in the KTCB for the QR TCB.

  4. SUMM FORMAT ASID(X'aaaa') where aaaa is the ASID of the CICS region. This displays the TCB information for the region.

  5. Enter F 'TCB: tttttttt' where tttttttt is the MVS TCB address of the CICS QR TCB. If the WLIC that follows the PRB under the TCB is 00020001 and the LINK field is 01xxxxxx, this indicates that the TCB is in a wait. In this case, the OPSW pointed into DFHDSDS3+940 but the offset might be different in newer releases of CICS. This is a normal wait under CICS. CICS is just waiting to be redispatched by MVS.

  6. SYSTRACE ALL displays the system trace. Look at the DSP entries to determine the ASIDs that are being dispatched by MVS. In this case, there were no trace entries for CICS.

  7. SELECT ALL displays the jobname associated with the ASIDs you see in the system trace.

  8. SUMM FORMAT JOBNAME(xyz) where xyz are the jobnames associated with the ASIDs found in the system trace displays the TCB information for the job. Locate the ASCB by entering F ASCB then find the the dispatching priority (DPH) of the address space.
    ASID JOBNAME    DPH (dispatching priority)
    0080 WDB035B     41
    0086 WDB135D     41
    008F WDB135A     41
    0095 DBPADBM1    8C

These ASIDs all had a higher dispatching priority than CICS which had a priority of 3B. Therefore, the dispatching priority for CICS was not high enough so CICS was never being dispatched. In this case, the dispatching priority of the DB2 address space (DBPADBM1) was 8C which is much higher than the dispatching priority of CICS. The dispatching priority for CICS should be at least as high as the dispatching priority of DB2.

Resolving the problem

Review your z/OS MVS workload management policy for the performance goals for the work that is being carried out by the CICS region. In this case, the importance of the performance goals for the CICS work should be made the same as the importance of the performance goals for the DB2 work. For guidance on using MVS workload management, see z/OS MVS Planning: Workload Management in the IBM Knowledge Center.

Related information

Steps for examining address space dispatchability
IXC messages

Product Alias/Synonym

CICS/TS CICS TS CICS Transaction Server

Rate this page:

(0 users)Average rating

Document information


More support for:

CICS Transaction Server
MRO

Software version:

3.1, 3.2, 4.1, 4.2, 5.1

Operating system(s):

z/OS

Reference #:

1178977

Modified date:

2014-07-28

Translate my page

Machine Translation

Content navigation