MVSFORUMS.com

[kavi]

Hi all,

Here is my problem.

Intially Iam reading a sequential file and storing some required values into a COBOL internal table. Later Iam reading this internal table and build a key for reading VSAM file. The job was got abended some times
for record not found for a KEY, but the record is originally available in the VSAM file. If I rerun the job the job was abended with the same reason but this time the KEY was different.

Iam not able to locate where the problem is?

Please help me out on this.

Thanks,
Kavi

[jsharon1248]

There's nowhere near enough information for anyone to provide a meaningful answer. It's most likely a logic error.

[kavi]

jsharon1248

Please let me know what kind of info's you are expecting So that I will provide you on this abend.

Thanks,
Kavi

[Terry_Heinze]

How are you loading the internal table?
Are you using an ODO clause?
If so, does your depending on clause reflect the actual table size?
Are you using a serial or binary search?
If binary, are the keys in sequence as required?
When your program abends with a "different" key, could it be because your logic has added a new record in the VSAM file, therefore the restart will "find" the record during the restart but not the 1st time you abended?
Can you use a debugging tool like Xpediter to monitor your program to help determine your problem?
_________________
....Terry

[kavi]

Thanks Terry,

Yes it uses ODO but i verified after your post and the depending on clause reflects the actual table size.

The problem with debugging this is, iam not sure on what key the program was abended. And also my program was not having any logic to add a new record in the VSAM file. But still I tried with reading the VSAM file for 10 times if record not found comes rather abending it first time itself , but this also failed.

Is this related to any memory problem. B'coz Iam writting a report in to sysout after processing the VSAM file.
Please let me know if you need any other info's.
Thanks,
Kavi

[jsharon1248]

Although possible, it's highly unlikely that you're dealing with any type of 'system error'. Most likely, you're going to find a flaw in your logic. What I'd recommend, is to start adding DISPLAY statements to your program working backwards from the READ that's failing. DISPLAY the variable specified in the RECORD KEY clause of the SELECT ASSIGN statement immediately before issuing the READ and compare the values to the actual values on the VSAM file. Keep in mind that LOW-VALUES and SPACE are not the same, so pay close attention to any white space. There's no magic that we can apply without actually seeing the code to tell you what the problem is. It could be possible that you're corrupting values in the internal table, that you're not formatting the keys properly, or even another process might be running that's updating the file.

[kavi]

Thanks jsharon1248,

The job not abended frequently, but once in a week or twice in a week.

Actually the job got abened today also. I have put display statements as you said and restarted it, but unfortunaly this time the job got abended for diffrent key. Manually verified the key for any junk and it seems there is no. The VSAM file will be updated once in a week and that also in weekend.

My doubt is if large volume of data will be written into internal table is that cause any problem

Please refer the table definations below, is ther anything wrong !!

Table declaration 1

[jsharon1248]

A couple things. Stop abending the program when the READ returns FILE STATUS '23'. Issue a message, display the key, and continue. If you have to abend, at least issue a message with the key. Also, what happens between the time that the input file is generated, and the time your problem program uses it?

[kolusu]

Why do you have 2 internal tables? Are u loading the vsam cluster into an internal table? and what is the cobol declaration of vsam key and the corresponding key definition you are building in the program

btw if your vsam key is a comp-3 key here is something you might want to look into which might be the problem

http://www.mvsforums.com/helpboards/viewtopic.php?p=25674#25674

[kavi]

Kolusu,

The input is from MQ, so we used two tables offcourse third one is also used. The request and response will be written separately into these tables for further processing.

VSAM KEY is not COM-3.

Here is the key declaration

[expat]

What is the abend code that you are getting ?
_________________
If it's true that we are here to help others,
then what exactly are the others here for ?

[jsharon1248]

You realize that this statement is just wasting time, don't you?

[kavi]

Hi all,

I found a blind solution for this. Iam really not sure how this is working. Please advice.

I changed the code to CLOSE the VSAM file if Key not found condition comes, Opened the file aging and reading the file for the same key using Start. Now the job went thru fine without any issues.

Please advice is there any problem with my VSAM KSDS file.

Thanks,
Kavi

[jsharon1248]

First, I doubt the CLOSE has anything to do with this. As long as you code ACCESS DYNAMIC in the FD, you can issue the START without closing the file first. Second, I'll bet you're using the >= condition in your START, not an =. Somewhere, I think you're program is not building the key the same way that it's generated on the VSAM file. You've only given minimal details, so we don't have a lot to work with. But from what you have told us, I think this is an issue with an inconsistent use of SPACES and LOW-VALUES, maybe even ZEROES. You should look into this further. You have not solved the root cause, you merely covered the symptom.

[kavi]

jsharon1248,

Verified all the way and Iam sure by building the key is correct. B'coz after closing and opening the file i used the excisting same variables for START. Initially I tried only START without closing and opening the file, but the result was same. But after closing , opening the file START and NEXT read was succes. Iam not sure how this was, that is the reason I put "I found a blind solution for this" in my previous post. For start Iam using >=
As per my second post let me know what kind of info's did you expecting from me, so that i can provide you for your analysis.

Thanks,
Kavi