IDMS Error Code '0302'

seahawk789 · New User Joined: 22 Feb 2010 Posts: 56 Location: Cochin

For quite some time now I am facing the IDMS error code '0302' while acessing an IDMS record from a cobol module. The interesting point is that this does not happen always and when I get this error I just restart the job (without making any changes) and it completes fine. But so far I have not able to find the root cause of the same

When I googled I found out that the reason for 0302 could be any of the following:

1) DBKEY may have a wrong value, nulls, zero, or overlaid working storage
2) Record name is incorrect
3) Wrong Subschema
4) DBKEY is outside of page range for Area

As restarting solves the issue, I eliminated points 2 and 3 above. Also as I am not using explicit use of the DB-KEY (Usages like, moving a working storage variable to the DBKEY and then CALCing the IDMS record based on that key, OBTAIN CALC <RECORD NAME>) in the module I don't think point 1 also may be a possibility.
So I suppose it may be point 4 above I don't exactly understand what the issue means in terms of program code.

My usage in the program is like, OBTAIN FIRST <Record name> WITHIN <Area>, OBTAIN NEXT <Record name> WITHIN <Area>. No OBTAIN Calc <record name> is used.

Can any one help me out to understand what exactly could be the reason for the inconsistent appearance of IDMS error code 0302 in the above scenario?

Bill Woodger · Posted: Wed Jul 27, 2011 3:54 pm

I can't understand this "toss it in again and see if it works" after a failure, but there we go.

Is your step doing updates (I'm guessing not, but have to ask, but also thinking it would provide a reason)?

When it happens next, solve it, don't just bung it in.

Look for any more messages which might give some information to narrow down the possibilities.

robert_wood · Posted: Wed Jul 27, 2011 3:58 pm

Hi,
this inconsistency is very puzzling.
I would suggest checking for this error in your program, moving the DB-KEY to a displayable format and then displaying. Your friendly DBA (Don't Bother Asking, lol) would be very interested in a corrupt dbkey, which relates directly to the physical address of the record. As per 4) above, the page/line number which the dbkey represents may indeed be outside the DBA-defined page limits for that record/area. I have seen this before, but not since the '90's - could be that you have a corrupt orphan record which comes to light when doing an area sweep.
Since you are doing an area sweep for this record, is it possible that you are losing currency in the area by accessing different records in the same area ? That would explain the inconsistent results.
Hope this may help.
Cheers Rob

PeterHolland · Posted: Wed Jul 27, 2011 4:17 pm

ibmmainframes.com/about49713.html

seahawk789 · New User Joined: 22 Feb 2010 Posts: 56 Location: Cochin

Can deadlock casue this issue?

Bill Woodger · Posted: Wed Jul 27, 2011 5:34 pm

Nothing to indicate deadlock in the meanings of the error code you quote, so unless you have other reasons to expect this... like other messages, I don't see a reason to suspect it.

Bill Woodger · Posted: Wed Jul 27, 2011 6:13 pm

If a job "falls over" and you chuck it in again with everything the same, it will "fall over" again. It is a computer, that is what happens.

So, something is different.

Is there anything different when you re-run? Exactly what do you do to effect the re-run? Is there a possibiity that it is running alongside something which is doing updates (related to your locking question)?

Plus, please answer the earlier outstanding questions.

vasanthz · Posted: Wed Jul 27, 2011 6:27 pm

Hello,
I have not worked on DB2 or have much knowledge on it, but have encountered a similar situation in which a failed job ran successfully upon restart. The issue was resolved after increasing the REGION parameter on the job card.
ibmmainframes.com/viewtopic.php?t=54162&highlight=

Edited: ok never mind this post. My response seems irrelevant.

seahawk789 · New User Joined: 22 Feb 2010 Posts: 56 Location: Cochin

@Bill Woodger: Answers to the earlier questions, there are no update steps in the program, all I do is obtain NEXT/FIRST, and from the spool I saw that while I am excecuting the statement 'obtain NEXT' it is encountering 0302. Regarding the second question I am not doing a thing when restarting. Just running exactly the same job again.. Thats why I thought even Deadlock may be an issue. But as u said there were no messages related to that. Hence thats not a possibility. Even if there is some corrupt DB2 key, as robert_wood said it should be happening every time I restart.. I am wondering how can IDMS be so strange!!

Bill Woodger · Posted: Wed Jul 27, 2011 7:41 pm

Is there a possibility that you are running alongside something doing updates? Then we have a change, because the state of the database has changed (like no longer being updated).

Can you confirm that you have checked for other messages, console, syslst etc? Is there some job that is running at the same time for more than one failure?

dbzTHEdinosauer · Posted: Wed Jul 27, 2011 8:00 pm

restart and rerun are two different things.

rerun implies that the run-unit is 'started' again, and it performs the same processing.

restart implies that the run-unit is 'started' again,
but the run-unit determines that processing should start not at the beginning
but at a later point (e.g. input record 97),
finds that point,
and then starts processing.

so, are you re-running,
or are you restarting?

robert_wood · Posted: Wed Jul 27, 2011 8:01 pm

Are you running your program with the c.v. up or local mode ?
If the former, you should find a related DC-prefixed message on the log, which can view using OLP.
It is unlikely that the DBMS is static or that you have sole access; clearly, the database cannot be in an identical state for each run.
Are you accessing one record (type) only in your area sweep ? This matters...
Have you displayed the offending db-key and accessed using OLQ or DMLO (or whatever you have) to confirm that the db-key which you have in W-S actually exists as a record viz. storage has not been over-written ?
Questions, questions...

Best Rob

PS IDMS strange, how very dare you !
It's an acronym for It's Done with Mirrors and Smoke, you know.

seahawk789 · New User Joined: 22 Feb 2010 Posts: 56 Location: Cochin

@Bill Woodger: There is a possibility that someone else may be running alongside doing some updates. But not me and I am not sure who is doing that

and what do you mean by the state of the database has changed ?
Also there are no messages in console, syslst etc.. Only in the sysout of the module I find this error.

@dbzTHEdinosauer: When the job abend I submit it again, without doing anything. Does that come under restart or rerun ? I am not sure.

@robert_wood: I am running in local mode. Regarding the record types, I have a CALC record (IDD1) and a Via record (IDD2) under IDD1. I am sweeping all the IDD1 records and all the respective via IDD2 records under that. I am not displaying the db-key

and I don have the liberty to change the cobol code to display it.

P.S: Sorry for calling IDMS strange!!

dick scherrer · Posted: Wed Jul 27, 2011 9:10 pm

Hello,

Bill Woodger · Posted: Wed Jul 27, 2011 10:29 pm

If something else updates the database while you are reading it, then your little wander through the database has the potential to loose its way (some sort of position information that you are using is now changed, so when you try to continue from it you get a big bang).

I'd suggest 1) try to establish which other jobs are running when a few examples of your job fails, looking for something common. 2) talk to production control/scheduling people to find out which jobs are updating the database you are using (they must know for restarts in the case of failures).

Again, I will boldly state,

if a job fails, it will fail again if re-submitted with no changes of any type.

If you are not making changes of any type and your step now succeeds, then the change that must be happening must be happening external to your processing.

Rats. What about your jcl prior to the step that is failing? Is that "doing anything" differently when you toss it in again?

seahawk789 · New User Joined: 22 Feb 2010 Posts: 56 Location: Cochin

Sorry for resurrecting the post again. But even after couple of years our job still abends at times with 0302 and when restarted it works fine.

On thorough analysis of our code I saw that our code does not have a FINISH IDMS statement. Also the job runs 10-20 times on an iterative manner. So can the absense of an IDMS FINISH statement on top of the job being iterative cause a 0302 ?