View - Module EBCS22EP AND JES3 EOB PROCESSOR DUMPS
Article ID: 240378
Updated On:
Products
Issue/Introduction
We received following from our OSS team. Is this related to CAVIEW? What seems to be the issue?
Dumps are no longer occurring, they backout the change that added the //CEEOPTS DD to the procedure.
The jobname is GR0WGENR
Seems they just upgraded DB2 there 4/5? Are dumps stills occurring. What is the job name?
On ML2W, there are a bunch off dumps with the following title that were taken last week:
COMPON=JES3 EOB PROCESSOR,ISSUER=IATDMEB,COMPID=SC1BA
We were trying to pass LE parms to a DB2 stored procedure using the following;
//CEEOPTS DD *
Parms here
The dumps were caused by multiple OPEN TYPE=J svcs issued for the CEEOPTS DD out of module EBCS22EP.
Looks to be CA View product, see an old 12.2 related knowledge issue.
Can you contact the vendor and see if they have a solution?
Environment
Release : 14.0
Component : View
Resolution
There was nothing unusual seen with the processing in the dump provided by the client, except that IBM had an open-ended OPEN for CEEOPTS with return code 12.
==> The RBs for TCB 009C9CD8 are there, and the trace there is OPEN SVC 19 for CEEOPTS from the application program:
0000 0103 009C9CD8 SVC 13 00000000_0BE5C1EE 00000003 3100B7B4 00000000
07850000 80000000
IBM OPEN Allocation storage for ACB for CEEOPTS DD * data set
000A 0103 009C9CD8 SVC A 00000000_00E4B538 00E4B490 000000B4 90E4B536
07841000 00000000
000A 0103 009C9CD8 SVCR A 00000000_00E4B538 00000000 000000B4 00082048
07841000 00000000
==> IBM OPEN issues SYNCH SVC to go back to problem state for opening of ACB
000A 0103 009C9CD8 SVC C 00000000_00E4B6E2 00E4BFCD 00000000 00000080
07541000 00000000
==> IBM OPEN issues OPEN TYPE=J SVC 22 for ACB for CEEOPTS DD
0016 0103 009C9CD8 SVC 16 00000000_00E4BFDC 00E4BFCC 00000000 00082048
47850000 00000000
==> In order for Deliver to receive control after OPEN TYPE=J SVC 22 of ACB for CEEOPTS DD, Deliver reissues OPEN after SYNCH to problem state like IBM code does. This is standard protocol for receiving control after OPEN. All registers at the time of reissuing OPEN TYPE=J SVC 22 are identical to IBM OPEN TYPE=J SVC 22.
0016 0103 009C9CD8 SVC C 00000000_2E73A332 2E73A343 00000000 00082048
07041000 80000000
0002 0103 009C9CD8 SVC 16 00000000_2E73A354 00E4BFCC 00000000 00082048
47851000 80000000
==> Deliver recognizes its reissuing of OPEN TYPE=J above and will branch to IBM OPEN SVC 22 (really next open intercept which in this case is IBM OPEN SVC 22) at address 00E1F000 to complete open of CEEOPTS. You can see that we did enter into IBM OPEN SVC 22 code with TIME SVC was issued from its code at offset 7A (00E1F07A).
000E 0103 009C9CD8 SVC B 00000000_00E1F07A 00FD5430 00000000 00000001
07543000 80000000
000E 0103 009C9CD8 SVCR B 00000000_00E1F07A 00000000 004486D3 0122095F
07543000 80000000
==> It can't be determined what happened after that point, but IBM OPEN SVC 22 ends with return code 12.
There is no error code apparent in ACBERFLG
0016 0103 009C9CD8 SVCR 16 00000000_2E73A354 0000000C 00000950 009A46B0
47851000 80000000
==> The SVC 3 after the return to SVC 22 causes return from SYNCH macro to get back to supervisor state
0002 0103 009C9CD8 SVC 3 00000000_00FD5482 0000000C 00000048 7F635CB8
47850000 00000000
0002 0103 009C9CD8 SSRV 78 814D5ED2 0000FF03 00000088 009C7408
01030000
0002 0103 009C9CD8 SVCR C 00000000_00E4B6E2 0000000C 00000048 7F635CB8
07541000 00000000
==> This same return code is returned with previous IBM OPEN TYPE=J SVC 22.
0002 0103 009C9CD8 SVCR 16 00000000_00E4BFDC 0000000C 00000048 7F635CB8
47850000 00000000
==> IBM code also issue SVC 3 to return from its SYNCH macro to get back to supervisor state
0002 0103 009C9CD8 SVC 3 00000000_00FD5482 0000000C 00000048 7F635CB8
47850000 00000000
0002 0103 009C9CD8 SSRV 78 814D5ED2 0000FF03 00000088 009C7408
01030000
0002 0103 009C9CD8 SVCR C 00000000_00E4B6E2 0000000C 00000048 7F635CB8
07541000 00000000
==> Now back into the original OPEN SVC 19 where IBM issues IEC141I message.
It cannot be determined exactly which WTO issues the IEC141I message since storage is not available.
000C 0103 009C9CD8 SVC 23 00000000_09F059A2 00FE9160 00000000 30224EF8
07040000 80000000
0002 0103 009C9CD8 SVC 23 00000000_09F05B22 7F609D48 00000001 30224358
07041000 80000000
==> Then IBM OPEN abends with 013-C0 error
0006 0103 009C9CD8 *SVC D 00000000_00E34718 000000C0 00E34A20 A4013000
07541000 80000000
------------------------------------------------------------------------------------
It was suggested that the client open an issue with IBM and supply the dump along with the above information and inquire as to why it is issuing S013-C0 message for CEEOPTS and why it is rejecting the OPEN. The ACB that IBM allocated is at address 00082048.
The Deliver code does not issue this type of abend or return OPEN with a non-zero return code.
Feedback
