View previous topic :: View next topic
|
Author |
Message |
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? |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
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. |
|
Back to top |
|
|
robert_wood
New User
Joined: 04 Jan 2011 Posts: 8 Location: Portsmouth, UK
|
|
|
|
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 |
|
Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009 Posts: 2481 Location: Netherlands, Amstelveen
|
|
Back to top |
|
|
seahawk789
New User
Joined: 22 Feb 2010 Posts: 56 Location: Cochin
|
|
|
|
Can deadlock casue this issue? |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
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. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
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. |
|
Back to top |
|
|
vasanthz
Global Moderator
Joined: 28 Aug 2007 Posts: 1744 Location: Tirupur, India
|
|
|
|
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. |
|
Back to top |
|
|
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!! |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
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? |
|
Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
|
|
|
|
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? |
|
Back to top |
|
|
robert_wood
New User
Joined: 04 Jan 2011 Posts: 8 Location: Portsmouth, UK
|
|
|
|
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. |
|
Back to top |
|
|
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!! |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
|
|
|
|
Hello,
Quote: |
When the job abend I submit it again, without doing anything. Does that come under restart or rerun ? I am not sure. |
This "depends". . . It may be either.
My guess is that the code is "walking on" something (or not initializing it) in some case(s) causing the problem when the database is referenced. If it is like quite a few of these, it has been "broken" for a long time (unless the error only started recently). The problem code may have been there so long that everyone "knows" it is ok because it has run for years. |
|
Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
|
|
|
|
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? |
|
Back to top |
|
|
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 ? |
|
Back to top |
|
|
|