Odd VSAM problem...

[ShawnStanford]

A pirate walks up to a bar and says, "Arrr, I'll be havin' a beer." The bartender pours him a beer and sets it down, then notices that the pirate has a steering wheel sticking out of the fly of his pants. "Hey, buddy," the bartender says. "Does that steering wheel bother you at all?" The pirate replies, "Arrr, it be drivin' me nuts."

And this problem is driving me nuts...

Old code, not mine (written by a foreign contractor), so I take no responsibility for its current condition. That being said: I have a program that calls a program, passing a transaction record. The called program attempts to match that transaction up to a VSAM file record before passing back. In the course of this, the called program calls another program that does the VSAM file handling (start, read) via an AIX.

If the first called program isn't happy with the VSAM record, he'll ask for another from the second called program. This goes on until the second called program reaches the end of the file and returns a flag instead of a record. At that point the first called program gives up.

Here's the problem: subsequent calls to this chain don't work. The first called program calls the second called program and the second called program does a 'start' and then a series of 'read's. It gets zero status codes from VSAM for all operations, but no data is returned on the reads: the record is the same as it was when doing the start. Obviously, this is causing the first called program to puke violently.

I've tried everything I can think of to get the file back on track: doing a start with low values before the keyed start, doing an open and close after hitting end of file, carefully manipulating the reads to stop any reads past end of file. Nothing seems to help.

Anybody? Anybody? Bueller?

 

[razalas]

You might try showing the linkage (i.e. CALL, LINKAGE SECTION and PROCEDURE statements) between these programs. That would be my first suspect. Are you doing something to imply USING BY VALUE instead of USING BY REFERENCE?

This could also be a problem with the initial state of the called programs. Sounds like the code is written intending to preserve the current state of program between CALL's but perhaps each time the called programs are invoked they are being set to INITIAL state.

Code what you mean,
and mean what you code!
But by all means post your code!

Razalas

 

[WMK]

Just to add to that last note:

You can "force" a subprogram into "initial state" by

A) CANCEL it between calls

B) code it with "IS INITIAL" inprogram ID.

Bill Klein

 

[ShawnStanford]

The second called program - the one actually doing the I/O - needs to retain its storage between calls, since it has the FD for the file and such.

I don't think it's a 'by reference' problem, since the two data items passed back and forth - the record and a status word - make it just fine.

The thing that is really killing me is the fact that I can't seem to 'restart' and get a fresh pass at the file after an 'end of file' condition. Yet, the status codes are consistently zeros.

Hmm... I think I'll try cancelling it when I get a bad return back. I assume that will force an initialization on the next call. Maybe that will 'reset' the file...

 

[TLeaders]

NetSerfer

I have not worked on IBM gear since the early 70’s so take this with a grain of salt.

Based on your description I assume that the program you are calling is passing the actual file-status name.
Program A calls Program B and it call the file-system. The first time and reads to the end of file.
Program A sets the file-status to 0 and calls Program B again. Program B thinks the status is good because it has the 0 passed form Program A and attempts reads the next record. The file-system knows that it is at end of file and returns no records.

Suggestions: In Program B change the file-status flag that you are passing to file-status2. Move file-status to file-status2 just before your return from Program B.

Good luck
Tom

 

[ShawnStanford]

Thanks everyone for your help, but it was a case of 'Duh'.

The problem was that an internally maintained end-of-file flag wasn't actually being maintained; it would be turned on but not turned off. This controlled the movement of any retrieved records to linkage for passing back to the calling program. VSAM was correctly returning good status codes, but since this end of file flag was still on, the records weren't being passed back, causing the calling program use CPU like it was going out of style and to puke violently all over spool.

I didn't notice it until now for the simple reason that I thought I was looking at an 88 level defined off the VSAM status word. I was looking at the code for the zillionth time this afternoon when it just clicked that I was looking at a stand-alone flag that wasn't being reset and, five minutes and nine lines of code later, it was fixed.

I hate it when I do that...