Troubleshooting
Problem
When the EDIS transaction is invoked from a blank CICS screen, we receive the following error:-
Continuous Receive request unsuccessful, message CR0040 was logged.
Error messages in the WDI Event Log:
VN1019*08*A Timeout error occurred while DataInterchange was waiting for Expedite/CICS to complete a continuous receive termination request. Mailbox (Requestor Profile) ID =
Diagnosing The Problem
After user has ran the Recovering Continuous Receive steps in the WDI 3.3.0 Programmer's Reference Guide on page 244 the user still experienced the same problem.
We checked the Expedite/CICS settings via LGO1 using the SYSTEM DEFAULT for the particular account and userid for the associated C.R. session and found the following settings were different between the working and non-working Region:
Force user to logon... < Y > Y - yes N - no
Auto create user...... < N > Y - yes N - no
We had customer to reverse those two values to the following:
Force user to logon... < N > Y - yes N - no
Auto create user...... < Y > Y - yes N - no
Note: This is the default setting
We went through the process again and got the same results. While the C.R. was finally stopped as per a check using LGO1, it seems that this occurred right after EDIS timed-out. This implies that there may be a deadlock on an ENQ resource between EDIS and an Expedite/CICS transaction; such as from recovery being defined on the Expedite/CICS VSAM files, hence causing Expedite/CICS to have to wait for EDIS to end/timeout before it can update the file to mark it as stopped.
The Expedite/CICS Program Directory says:
7.1.5 EXPEDITE/CICS DATA SET CONSIDERATIONS
Expedite/CICS requires that its data sets not be defined as recoverable. Expedite/CICS handles its own recovery between itself and IE by the use of the recovery levels IE offers, and would be severely impacted if the files were defined as recoverable. For example, it is very possible and likely that deadly embraces and deadlocks, and loss of data occur when the Expedite/CICS data sets are defined as recoverable. This is due to the way that file recoverability works with regards with the locking up of records when certain file actions are taken, and when they are released.
Use "CEDA VIEW FILE(EXP*) GR(*)" to check all of your VSAM file definitions for Expedite/CICS to ensure they are defined as follows:
RECOVERY PARAMETERS
RECOVery : None None | Backoutonly | All
Fwdrecovlog : No No | 1-99
BAckuptype : Static Static | Dynamic
It was found that the only one of the VSAM files that was marked as Recoverable.
Resolving The Problem
User changed the EXPDERR dataset to None for RECOVery and that resolved the problem. Also be sure these other Expedite/CICS VSAM files are defined with RECOVery = None:
EXPDTST
EXPDSRC
EXPDPTF
EXPHPHP
EXPRDAT
EXPSDAT
EXPDLKP
EXPDKEY
After changing the recovery parameters accordingly, clear out the previous C.R. via these quick steps:
- EDIZ
- EDIW to execute WDI command: PERFORM CLOSE MAILBOX WHERE REQID(<mailbox>)
- and then use LGO1 (SYSTEM DEFAULT id) to delete the associated C.R. userid.
Was this topic helpful?
Document Information
Modified date:
16 June 2018
UID
swg21643925