[hercules-390] Abend S0C4-3B DSNIREDR+045E using DB9G under ADCD 1.10

[[e-mail] [hercules-390]]

Getting some very weird stuff happening when using DB2 V9 under ADCD 1.10

I issue SELECT EMPNO FROM DSN8910.EMP; - and I get successful 42 rows returned.

I then issue SELECT * FROM DSN8910.EMP; and I get

IBM0281S A prior condition was promoted to the ERROR condition.
From entry point DSNTEP2 at statement 2326 at compile unit offset +00003CB8 at entry offset +00003CB8 at address 1E552D78.
DSN3201I -DB9G ABNORMAL EOT IN PROGRESS FOR USER= CONNECTION-ID=BATCH CORRELATION-ID=TP2
JOBNAME=TP2 ASID=001C TCB=008CF030
IEA794I SVC DUMP HAS CAPTURED:
DUMPID=001 REQUESTED BY JOB (TP2)
DUMP TITLE=DB9G,ABND=0C4-0000003B,U= ,M=(N),C=910.DMC -DSNISDLE,
M=DSNTFRCV,LOC=DSNIDM .DSNIREDR+045E
IEA611I COMPLETE DUMP ON SYS1.ADCD.DMP00001
DUMPID=001 REQUESTED BY JOB (TP2) FOR ASIDS(001C,0049,0048)
ERROR ID = SEQ00024 CPU41 ASID001C TIME13.19.19.9

1) I have researched IBMLINK extensively and found no direct hits. I installed some PTFs which were close, but it made no difference. This makes me think it is a Hercules type problem not IBM software, that's why I am posting here.

2) I have installed the UNICODE fixes for 1.10 as described in "OA48941: UNICODE CONVERSION INFORMATION SERVICE FAILS RC8 RSNB SYSTEM TOD CLOCK TIMESTAMP EXCEEDS 12/15/2015 13:24:57.238527 CUNLINFO" - this also made no difference.

3) The SQL above which works selects only a primary key, so it probably only goes to the index. It appears that when I ask for the data it fails. But the following DOES work!
SELECT PROJNO FROM DSN8910.PROJ; -- primary key access - 20 rows
SELECT *FROM DSN8910.PROJ; -- non-primary key -- 20 rows
SELECT ACTNO FROM DSN8910.ACT; -- 18 rows
SELECT * FROM DSN8910.ACT; -- 18 rows

I am out of ideas, any suggestions most welcome!
Thanks
D

[[e-mail] [hercules-390]]

Post by ***@isi.com.au [hercules-390]
This makes me think it is a Hercules type
problem not IBM software, that's why I
am posting here.

If you believe it might be Hercules, I'd
suggest retrying under:

1. Hercules 3.07
2. Hercules 3.12
3. Hyperion

If they all fail, I suggest retrying on real
iron. And if that fails, then raise a
problem with IBM.

BFN. Paul.

[Joe Monk [e-mail] [hercules-390]]

0C4-3B is a page translation issue.

What OS are you running? What does your hercules config file look like?

Joe

Post by ***@isi.com.au [hercules-390]
Getting some very weird stuff happening when using DB2 V9 under ADCD 1.10
I issue SELECT EMPNO FROM DSN8910.EMP; - and I get successful 42 rows returned.
I then issue SELECT * FROM DSN8910.EMP; and I get
IBM0281S A prior condition was promoted to the ERROR condition.
From entry point DSNTEP2 at statement 2326 at compile unit
offset +00003CB8 at entry offset +00003CB8 at address 1E552D78.
DSN3201I -DB9G ABNORMAL EOT IN PROGRESS FOR USER= CONNECTION-ID=BATCH CORRELATION-ID=TP2
JOBNAME=TP2 ASID=001C TCB=008CF030
DUMPID=001 REQUESTED BY JOB (TP2)
DUMP TITLE=DB9G,ABND=0C4-0000003B,U= ,M=(N),C=910.DMC -DSNISDLE,
M=DSNTFRCV,LOC=DSNIDM .DSNIREDR+045E
IEA611I COMPLETE DUMP ON SYS1.ADCD.DMP00001
DUMPID=001 REQUESTED BY JOB (TP2) FOR ASIDS(001C,0049,0048)
ERROR ID = SEQ00024 CPU41 ASID001C TIME13.19.19.9
1) I have researched IBMLINK extensively and found no direct hits. I
installed some PTFs which were close, but it made no difference. This makes
me think it is a Hercules type problem not IBM software, that's why I am
posting here.
UNICODE CONVERSION INFORMATION SERVICE FAILS RC8 RSNB SYSTEM TOD CLOCK
TIMESTAMP EXCEEDS 12/15/2015 13:24:57.238527 CUNLINFO" - this also made no
difference.
3) The SQL above which works selects only a primary key, so it probably
only goes to the index. It appears that when I ask for the data it fails.
But the following DOES work!
SELECT PROJNO FROM DSN8910.PROJ; -- primary key access - 20 rows
SELECT *FROM DSN8910.PROJ; -- non-primary key -- 20 rows
SELECT ACTNO FROM DSN8910.ACT; -- 18 rows
SELECT * FROM DSN8910.ACT; -- 18 rows
I am out of ideas, any suggestions most welcome!
Thanks
D

[[e-mail] [hercules-390]]

DSNIREDR is trying to execute DB2 edit proc DSN8EAE1. I am not sure why you are getting the 0C4-3B but I see that other 0C4 abends can occur if the V8 DSN8EAE1 is mistakenly used in DB2 9 for z/OS - it appears that ADCD 1.10 came with both versions. DB2 V8 is the last version where 31 bit addressing was used and DB2 9 used 64 bit addressing.

Jim

[Joe Monk [e-mail] [hercules-390]]

Sounds like you hit it... 64 bit vs 31 bit addressing... explains the
translation sub code.

Joe

Post by ***@yahoo.com [hercules-390]
DSNIREDR is trying to execute DB2 edit proc DSN8EAE1. I am not sure why
you are getting the 0C4-3B but I see that other 0C4 abends can occur if the
V8 DSN8EAE1 is mistakenly used in DB2 9 for z/OS - it appears that ADCD
1.10 came with both versions. DB2 V8 is the last version where 31 bit
addressing was used and DB2 9 used 64 bit addressing.
Jim

[[e-mail] [hercules-390]]

Hi Jim,

That's greatly helpful - after struggling I now know where to look. I have done the following to try and fix it, but still no joy!

1) removed the DB2V8 volumes from my startup
2) modified IEFSSN to NOT enable the start of DB2V8
3) re-assembled DSN8EAE1 using extract from job DSNTEJ1.
4) renamed DSN8EAE1 to try to force a 806 abend - didn't get it - very strange
5) scanned everywhere for another copy of the module - can't find it.

Will continue hunting. Trust me to decide to experiment on the only sample table with an EDITPROC!
Thanks
D

[[e-mail] [hercules-390]]

It is likely that the old edit proc is still in the Library Lookaside Facility - perhaps also in some library in the link list or link pack area. Try issuing the following console command:

F LLA,REFRESH

If that does not help, you may need to look in places like SYS1.LINKLIB and whatever other libraries may be in the link list. Issuing the following command will display the libraries in the link list concatenation:

D PROG,LNKLST

It has been a couple of years since I had to do any of this so my memory on all the things to try is really rusty but hope this helps.

Jim

[Robert Prins [e-mail] [hercules-390]]

TSO DDLIST or TSO ISRDDN and then
M whatever

Post by ***@yahoo.com [hercules-390]
It is likely that the old edit proc is still in the Library Lookaside
Facility - perhaps also in some library in the link list or link pack area.
F LLA,REFRESH
If that does not help, you may need to look in places like SYS1.LINKLIB
and whatever other libraries may be in the link list. Issuing the following
D PROG,LNKLST
It has been a couple of years since I had to do any of this so my memory
on all the things to try is really rusty but hope this helps.
Jim

[Robert Prins [e-mail] [hercules-390]]

And between the to "LPA"

[Robert Prins [e-mail] [hercules-390]]

Between the two...

Post by Robert Prins ***@gmail.com [hercules-390]
And between the to "LPA"

[[e-mail] [hercules-390]]

Hi All,

Many thanks for your ideas. I believe that I have come up with a workaround rather than a solution.

So the ADCD 1.10 has both the DB2V9 and DB2V8 environments. I wasn't the only person getting this abend on the EMP table. Another friend was getting it one some personal tables as well. Those tables were working a couple of years ago, which is why we thought about the Unicode date problem.

We then assumed it was a DB2 bug, but couldn't find it. After the information provided here I assumed it was tied to the EDITPROC of DSN8EAE1, so I tried renaming it to force an 806 abend - but it didn't happen.

I then created a parallel version of the EMP table from the installation job DSNTEJ1. This works properly using the DSN8EAE1 editproc. I renamed DSN8EAE1 and got the 806 as expected, so I knew that I was running my module. I then concluded that there was some other corruption in the DB2V9 environment which caused DSNIREDR to abend before it got to the EDITPROC module.

As I said, I don't have the resources to nail down the problem. I am happy that I am able to have a workaround.

Thanks to all who gave me clues and ideas.
D





---In hercules-***@yahoogroups.com, <***@...> wrote :

Between the two...


On 30 December 2016 at 21:09, Robert Prins <***@... mailto:***@...> wrote:
And between the to "LPA"





--
Robert AH Prins
***@... mailto:***@...
No programming (yet) @ <http://prino.neocities.org/ http://prino.neocities.org/>