Bind abends with 0C4 when DEGREE(ANY) option is used

Venkata C

Hi!

We are running DB2 V8 on z/OS in compatibility mode. There is one
specific query (embedded as static SQL in a COBOL program) that causes
the bind job to abend when we use the DEGREE(ANY) option. The bind
works fine with DEGREE(1). The bind job binds the DBRM into a plan.

The query uses parameter markers. If we replace the parameter markers
with literals in the query, the bind goes through without problems.
Also, if we change the definition of the view referenced by the query,
we find that the problem goes away for certain view definitions. After
playing with the view definition for some time, it looks to us that the
problem occurs whenever the access path chosen for the query includes
(CP) parallel access for one of the tables involved (ACCESS_DEGREE = 0
in the plan table entry).

If anyone came across a similar problem, please advise.

Thanks and Regards,
Venkata

Nov 12 '05 #1

Venkata C

I should have said "host variables" instead of "parameter markers".

The view definition that causes the abend looks like:

Select ... From TableA
where field1 = :value1
and field2 = :value2
and ( exists ( correlated subquery 1) or exists (correlated subquery 2)
)

TableA (field1, field2) is a unique index. DB2 chooses CPU parallelism
for accessing this table for whatever reason - the plan_table entry has
ACCESS_DEGREE = 0, meaning that DB2 will decide on the degree of
parallelism after looking at the values of the host variables. There
will be at most one row retrieved from tableA. The reason for choosing
parallelism is unclear.

The only characteristic of the view rewrites that don't cause the abend
is that DB2 doesn't choose parallelism for tableA's access. DB2 doesn't
choose parallelism when literals are substituted for host variables
either.

This is a PeopleSoft environment. We were originally getting this error
in a CLI client running on an AIX box, accessing the DB2 server on z/OS
through DB2 Connect. The query that selects from the view gets a -1224
SQL code, and further SQL requests a -30081 SQL code. At the same time
as the -1224 SQL code error on the client, we see message in the master
log on z/OS that a DB2 agent abended with a 0C4, reason code 0.

After a good deal of testing, we eliminated PeopleSoft and DB2 Connect
from consideration by reproducing the error in a COBOL program on z/OS.

Nov 12 '05 #2

Mark Yudkin

I suspect you're better off opening a PMR than hoping to get a resolution
here.

"Venkata C" <ve*************@gmail.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...

I should have said "host variables" instead of "parameter markers".

The view definition that causes the abend looks like:

Select ... From TableA
where field1 = :value1
and field2 = :value2
and ( exists ( correlated subquery 1) or exists (correlated subquery 2)
)

TableA (field1, field2) is a unique index. DB2 chooses CPU parallelism
for accessing this table for whatever reason - the plan_table entry has
ACCESS_DEGREE = 0, meaning that DB2 will decide on the degree of
parallelism after looking at the values of the host variables. There
will be at most one row retrieved from tableA. The reason for choosing
parallelism is unclear.

The only characteristic of the view rewrites that don't cause the abend
is that DB2 doesn't choose parallelism for tableA's access. DB2 doesn't
choose parallelism when literals are substituted for host variables
either.

This is a PeopleSoft environment. We were originally getting this error
in a CLI client running on an AIX box, accessing the DB2 server on z/OS
through DB2 Connect. The query that selects from the view gets a -1224
SQL code, and further SQL requests a -30081 SQL code. At the same time
as the -1224 SQL code error on the client, we see message in the master
log on z/OS that a DB2 agent abended with a 0C4, reason code 0.

After a good deal of testing, we eliminated PeopleSoft and DB2 Connect
from consideration by reproducing the error in a COBOL program on z/OS.

Nov 12 '05 #3

Venkata C

Mark,

We do have a PMR open, but it has been open for about three weeks. I
just wanted to see if anyone else is facing the problem.

Thanks,
Venkata

Nov 12 '05 #4