FEPI dump

CICS® dump routines are available for FEPI. These routines are under the control of the usual CICS selection mechanisms.

You generate interpretation of the FEPI areas of a CICS dump by specifying the SZ keyword from within the interactive problem control system (IPCS). SZ can take the following values:
SZ value
What is printed
0
No FEPI areas are interpreted.
1
All FEPI areas are interpreted, excluding the stacks.
2
All FEPI areas are interpreted, including the stacks.

If you are looking at a FEPI problem, first ensure the SZ TCB is active, and the FEPI Resource Manager is running. Look at the kernel and dispatcher prints to verify their presence.

If the SZ TCB is present, and the FEPI Resource Manager is running, the problem is probably caused by a wait or an abend. In the case of a wait, the dispatcher and kernel prints should show where it is located.

After looking at any FEPI trace entries, you should direct your attention to the output from the ‘SZ=2' dump formatting keyword. This displays all known FEPI control blocks. If you think a storage violation has occurred, use the dump storage manager options to display the contents of the FEPI storage subpools.

Here are some things that might help you identify a problem when you read the dump:
  • Were any errors reported during interpretation? If so, this may indicate a corrupt address pointer or a broken chain.
  • Follow all the pointers to associated control blocks (such as the conversation pointed to by the connection). Is this pointer correct? If not, this probably indicates corruption.
  • Are there the expected numbers of nodes, targets, property sets, and pools? If not, this can indicate a broken chain or an unauthorized deletion.
  • Does each pool contain the expected number of connections (that is, the number of nodes multiplied by the number of targets)? If not, this may indicate the failure of a FEPI ADD command.
  • Has each node been successfully acquired? If not, there is the possibility of z/OZ Communications Server definition errors. The ACB and RPL may contain z/OZ Communications Server sense information—perhaps a z/OZ Communications Server major node is inactive.
  • Is there successful communication with a target? If not, have APPLID and PASSWORD been correctly specified? If they are correct, is the back-end system running?
  • Are there any queued ALLOCATE commands? If so, this indicates that there are not enough connections for the pool to process FEPI conversations without queuing. This may be acceptable, or not, depending on your configuration.
  • Are the event handlers being run? If not, have they been correctly defined to CICS using RDO?
  • Are the event handlers being recursively invoked? If so, this indicates a problem with a FEPI FREE command, a storage violation, or an internal logic error.
  • Is information being correctly sent to the specified transient data queues? If not, are the queues defined as unrecoverable?
  • Are transactions being triggered from the TDQs? If not, are the transactions correctly defined to CICS?
  • Is there a current conversation? If so, this conversation may be causing the error. Is the data correct? Is there any z/OZ Communications Server sense information in the RPL?
  • Are the surrogate terminals correct? If not, the links between the nodes, pools, and targets may have become corrupted.
  • Are FEPI SEND or FEPI RECEIVE commands failing due to state errors? If so, look at the conversation and see if the states are correct. If they are not, the conversation has become out of step with the z/OZ Communications Server flow.
  • Is unexpected data being sent or received in formatted conversations? If so, there may be corrupt FEPI data. Look at FEPI's internal terminal character buffer.
  • Look at the queues. Are there any requests that look as if they have got stuck? If so, the FEPI work chains may be corrupt. However, it may be that the flow to satisfy the requests has not yet happened. If you think it should have happened, there may be communication problems.
  • Look at the FREE queue. The last z/OZ Communications Server event may be shown. If so, does it correspond with what you expected?
  • Is the behavior of a pool correct? If not, it is possible that the property set used to define the pool is incorrect. However, if the property set is shown, it could have been re-created since the pool was defined—treat property set definitions with care.
  • Are there any outstanding timer events that should have run? If so, this may indicate a chaining failure.
  • Has a timer-dependent action been delayed? If so, this could indicate that the TIMEOUT parameter on the command was incorrect.
  • Are you receiving all the data you expect? If not, have you set the correct end-of-flow condition on the FEPI RECEIVE (or CONVERSE) command?
  • Are there many transactions waiting on FEPI? If so, either back-end systems are not responding, or the FEPI Resource Manager has failed.
  • Has a z/OZ Communications Server dump been taken? If so, this may indicate a failure in one of the z/OZ Communications Server exits.