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 VTAM® definition errors. The ACB and RPL may contain VTAM sense information--perhaps
a VTAM 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? Investigation of the DCT
may help here.
- 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 VTAM 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 VTAM 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
simply 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 VTAM 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 VTAM dump been taken? If so, this may indicate a failure in one
of the VTAM exits.
This section describes how FEPI relates to the rest of CICS, and how its
presence is revealed by the other CICS dump formatting commands.
The problem determination process for FEPI is driven from the usual CICS
dump interpretation routines. The following sections describe what to look
for in the major CICS areas.
Dispatcher
You should see a task (CSZI) running under the SZ task control block. (However,
note that CSZI can run under the QR TCB while executing certain CICS functions,
such as starting transactions and writing to transient data queues.) If CSZI
is not present, then either FEPI is not in the system, or the FEPI Resource
Manager has failed.
Application programs waiting for responses from the FEPI Resource Manager
are shown as waiting on FEPI. (For details of FEPI waits, see the CICS Problem Determination Guide.)
Interval control
Any transactions that have been started by the FEPI Resource Manager, but
not yet run, appear in the interval control section.
Kernel
In the kernel, you should find a running task named KETCB SZ representing
the SZ TCB that FEPI uses. If KETCB SZ is not present, then either FEPI is
not in the system, or the TCB has abended.
You should find the CSZI task either running or waiting. If CSZI is not
present, then either FEPI is not in the system, or the FEPI Resource Manager
has failed.
If an abend has occurred, the usual information is available. The location
of the abend is indicated by the failing module, as follows:
- DFHESZ
- The application programming EXEC stub
- DFHEIQSZ
- The system programming EXEC stub
- DFHSZATR
- The FEPI adapter
- DFHSZRMP
- The FEPI Resource Manager.
Storage manager
Table 9 lists the CICS storage subpools used by FEPI.
You can use the storage manager dump facilities to display the contents of
these subpools. If you suspect a storage violation, a comparison of the contents
of these subpools with the areas interpreted by a FEPI dump may show where
the corruption has occurred.
Table 9. FEPI storage subpools
Name |
Type |
Chained |
Above or below 16MB line? |
Usage |
SZSPFCAC |
Fixed |
Yes |
Below |
ACBs |
SZSPFCCD |
Fixed |
Yes |
Any |
Connections |
SZSPFCCM |
Fixed |
Yes |
Any |
Common area |
SZSPFCCV |
Fixed |
Yes |
Any |
Conversations |
SZSPVUDA |
VAR |
Yes |
Any |
Various data areas |
SZSPFCDS |
Fixed |
Yes |
Any |
Device support extensions |
SZSPFCDT |
Fixed |
Yes |
Any |
Device-type control areas |
SZSPFCNB |
Fixed |
Yes |
Any |
NIBs |
SZSPFCND |
Fixed |
Yes |
Any |
Nodes |
SZSPFCPD |
Fixed |
Yes |
Any |
Pools |
SZSPFCPS |
Fixed |
Yes |
Any |
Property sets |
SZSPFCRP |
Fixed |
Yes |
Any |
RPLs |
SZSPFCRQ |
Fixed |
Yes |
Any |
Requests |
SZSPFCSR |
Fixed |
Yes |
Any |
Surrogates |
SZSPFCTD |
Fixed |
Yes |
Any |
Targets |
SZSPFCWE |
Fixed |
Yes |
Any |
DQEs |
[[ Contents Previous Page | Next Page Index ]]