KSDS File Status - 92

Gayathri P · New User Joined: 07 Oct 2011 Posts: 16 Location: India

I have converted a flat file (recl 100) into the below VSAM.
when I read that VSAM using the key (old-card), am getting logic-error '92'.

expat · Posted: Mon Feb 27, 2012 12:55 pm

And a code 92 is what ............
You have looked it up haven't you.

Bill Woodger · Posted: Mon Feb 27, 2012 12:58 pm

Also it is a Cobol rather than a VSAM question.

expat · Posted: Mon Feb 27, 2012 12:59 pm

Indeed it is and has now been moved

Dsingh29 · Active User Joined: 16 Dec 2008 Posts: 132 Location: IBM

your input record is of 99 length while you said recl =100 for flat file, please check following to start with your error research:
1. see if KSDS is properly populated
2. check the length of your key again.
3. try to increase the length of input record.

Bill Woodger · Posted: Mon Feb 27, 2012 1:14 pm

I got the same byte-count as Dave. You'll have to change that anyway.

What are you going to use those 88's for? The name you've given for 24, I don't understand. From the 88's it looks like you are doing sequential reads as well.

The minimal code you have provided shows a sequential read, yet you are setting up the key.

Either you are doing a sequential read without a prior position on the file, or you are doing a keyed read with the wrong (sequential) format for the READ statement. The KEY IS to Read The Fine Manual.

Gayathri P · New User Joined: 07 Oct 2011 Posts: 16 Location: India

After the read stmt I have displayed the FILE-STAT which is '92',Hence I ve raised this under VSAM .

File status 92 has given me the explanation as logical error.
As far as i checked , the key field length is correct, pos 1-16 and is correctly populated in KSDS too.

Thanks for pointing out the recl mismatch and it has been corrected.

Gayathri P · New User Joined: 07 Oct 2011 Posts: 16 Location: India

The 88 Variables ,I have just given some self defined flags for various status codes of the VSAM .

Please ignore the '24' which is not applicable in this case

Bill Woodger · Posted: Mon Feb 27, 2012 2:11 pm

Not "logical error" but "logic error". This means you have done somthing which does not make sense to the VSAM processing code.

In your case, when you get to the post, you have asked it to read the next record when there is no current record for VSAM to use to establish what record anyone would feel is the "next".

It is a "logic error" because your code asked VSAM to do something which does not make sense. It is a Cobol question because your code is in Cobol.

Maybe there are other exceptions, but except for an I/O error, those FILE-STATUSes you get in your program which are not those expected at the time are indicating problems with your code (sometimes it'll be the specification which is lacking, but usually you should have been able to think of those situations yourself; sometimes it'll be the file definition, which is more code that is either yours, or which you should have looked at).

EDIT: Crossed in the post. I'm not discouraging the 88s, just was curious as to whether they indicated random and sequential, and what you were expecting from the 24, which I'll now ignore. Still, the others should be adding to the information about your program...

Gayathri P · New User Joined: 07 Oct 2011 Posts: 16 Location: India

Bill Woodger · Posted: Mon Feb 27, 2012 2:19 pm

Click on the Manuals link at the top of the page. Choose a Cobol Language Reference. Look at Format 2 of the READ. Look at some other stuff at the same time, so you pick up something else as well.

Gayathri P · New User Joined: 07 Oct 2011 Posts: 16 Location: India

Thank you Mr Bill ,
Will definitley look into the reference .

The issue is resolved now. I just corrected the line order below ,

FILE STATUS IS FILE-STAT
RECORD KEY IS WS-KEY.

to

RECORD KEY IS WS-KEY
FILE STATUS IS FILE-STAT.

and it worked out.

Thank you all !!!

Bill Woodger · Posted: Mon Feb 27, 2012 4:02 pm

Really?

If the order mattered, I'd have expected the Compiler to notice and give you an error.

Same data? No other code changes?

You have DYNAMIC access. How do you think you are telling it to do a keyed read rather than a sequential read?

Gayathri P · New User Joined: 07 Oct 2011 Posts: 16 Location: India

I havent made any other change Sir.

In the same program , I am also performing a sequential read on another file and have given the access mode as SEQUENTIAL .

For KEY-READ I have tried with both RANDOM & DYNAMIC , and now after this change both are working.

To answer your question,in DYNAMIC I have populated the key value and made the READ ,

MOVE ws-number TO WS-KEY
READ INP-FILE.

Whereas in sequential jus staright away reading till the End Of file.

READ HBO-MASTER
AT END
(come out)
NOT AT END
(process)

Thats the only difference I had made in here .

Bill Woodger · Posted: Mon Feb 27, 2012 4:30 pm

OK. I'll try to find time to do a little checking, as that sounds interesting.

If you are only doing keyed reads on that file, then it is better to specify RANDOM. If doing a mix of keyed and sequential reads on that file, you must use DYNAMIC.

With DYNAMIC, READ without the KEY is going to do a sequential read.

Having said that, I've always used READ NEXT for a sequential and READ KEY for a keyed read, so can't be certain about what happens if you don't do that. It makes the program easier to read, and leave no doubt about either your intention or the compiler's actions.

Gayathri P · New User Joined: 07 Oct 2011 Posts: 16 Location: India

Yes I have realized the benefit of using RANDOM here.

So far I ve been using START , READ NEXT only for the READs using PARTIAL-KEYs . Will try using READ NEXT for sequential too.

Thanks a ton for ur help

Bill Woodger · Posted: Mon Feb 27, 2012 7:02 pm

For OPEN INPUT for a KSDS the default when nothing specified is a keyed read.

I have so far failed to create a '92' for keyed reads of a KSDS.

There is one change you made we forgot about, which was the length of the record.

The order of FILE STATUS and RECORD KEY makes no difference.

The 92, "logic error", should be saying "you're asking me (VSAM) to do something that does not make sense given, like writing input, reading output".

If you can make the problem return by changing the length of the record back to 99, I'd be interested in seeing a LISTCAT.

If you can't re-create it like that, then we'll get nowhere without seeing more of your code. If you like, and are allowed, you can PM me the whole thing :-)

Gayathri P · New User Joined: 07 Oct 2011 Posts: 16 Location: India

Yes !!!!

Its that recl change which is causing the difference.
I have recreated the bug , by reverting that change.

I still don't understand why it dint throw me some error like file attribute mismatch or so .. during execution itself , instead the job ran fine !!!

Gayathri P · New User Joined: 07 Oct 2011 Posts: 16 Location: India

I would appreciate a detail explanation for I dont have enough knowledge on compiler listing

enrico-sorichetti · Posted: Mon Feb 27, 2012 7:46 pm

unfortunately this is not a training forum...
if You have some/few lines that You do not understand post them and somebody will be glad to help.
but.... nothing more

Bill Woodger · Posted: Tue Feb 28, 2012 4:53 am

Have a look in the Language Reference about specifying the extended file status for VSAM files. The third field in the group that you define will give you the Reason Code returned from VSAM. If you do this and display the value, you will get a decimal 44.