search cancel



Article ID: 240378


Updated On:




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:
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?


Release : 14.0

Component : View


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                          
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

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

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.