Our SARXMS started task just issued a
SYMPTOM DUMP USER COMPLETION
CODE=0522followed by an
IEA794I SVC DUMP HAS CAPTURED: 187
DUMPID=009 REQUESTED BY JOB (SARXMS)
DUMP TITLE=SCHEDULER JCL FACILITY FAILURE,COMPON=SCHR-SJF,COMPI
The XMS task continues to process fine - why does XMS issue this dump?
This is a normal situation when you have network errors. Check your XMS log - you may see something like:
SARVLST1 CLACSAR _LB819099_VT LOSTERM RC=14 FORCED CTERM RECEIVED
EBCOCMD1 --> CANCEL CONID='CLACSAR _LB819099_VT' (LOST TERMINAL ERROR,
EBCOCNL1 CLACSAR _LB819099_VT - 5 User CANCELED by operator request
SARVXIT1 CLACSAR _LB819099_VT NSEXIT CLEANUP RPLCNTRL=800000 0000C006
The lost terminal exit executes in the VTAM ACB owning task not the terminal owning task.
The task that is being abended is the terminal owning task. Because the code being executed in the terminal owning task is not stopped, the cancel can occur during the execution of IBM code. When this happens, the ESTAE routines for the IBM code get control and may trigger an SVCDUMP.
This is normal. There is nothing that we can do to prevent this. XMS will continue to function. The terminal owning task will abend which is the desired result.
If you see:
SARVERR1 CLACSAR _CLTRF441_VT EBCVTAC4 REQ=RECEIVE RTNCD=1009 FDBK2=00000000
SARVERR1 CLACSAR _CLTRF441_VT RtnCd Analysis=Unconditional terminate
EBCOCMD1 --> CANCEL CONID='CLACSAR _CLTRF441_VT' (VTAM I/O ERROR, EBCVTERR)
EBCOCNL1 CLACSAR _CLTRF441_VT - 7 User CANCELED by operator request
then you will not get an SVCDUMP because the task that is requesting the cancel is the terminal owning task. The module EBCVTERR runs in the terminal owning task. When the cancel command is issued, the task then puts itself in a wait so no further processing can occur.