VSAM Status 46 - what else could be wrong?

BrantleyL · New User Joined: 03 Jun 2010 Posts: 14 Location: Dallas TX

I am getting a 46 on a VSAM file. I am VERY puzzled by this because I believe that I have coded so that this is not possible.

The program reads an input to get the keys to read the vsam file. It is reading the AIX.

VSAM status 46 means that no valid next record condion exists because:
1. The prior read resulted in an end-of-file
2. The previous read was not successful.

I don't think either of these apply because. If I get an EOF, the code will go read the next input record and do a start browse based on that key and read from there.

If the previous read is unsuccessful, the program abends.

This file is open for I/O in the CICS region. I kind of suspect that has something to do with it, but I am at a complete loss as to how this can happen. The program has been running without incdent for some time and this has only cropped up recently, but the last week data volume has pushed this program into running during the time CICS is up.

Any ideas would be appreciated!!

Robert Sample · Posted: Fri Jun 04, 2010 1:13 am

It is not at all clear to me what you are doing. Is the program with the 46 file status a batch program or CICS program? I ask because this statement implies it is CICS:

BrantleyL · New User Joined: 03 Jun 2010 Posts: 14 Location: Dallas TX

This is a BATCH program I am getting the status 46 on.

The program's function is to sync a VSAM file into a DB2 table.
The key to the vsam file is LSKU+BARCODE.
We are passed LSKU and need to sync any and all records with the same LSKU - typically one or two.

Here's the high-level process:
1) Read the input ("request" table).
2) Based on the keys just read (LSKU) start browse on the VSAM file
3) Read Next record.
4) If the keys match, perform the sync process.
5) loop back to #3.
6) if the keys don't match, loop back to #1.

The 46 occurs on the #3 read.

If the start browse gets something other than a zero, the job abends. It's not possible to actually hit eof on the start due to key structure of the file.

If the read fails, the program will abend.

So, I don't see how the program could go back and try another read. My wonder is if somehow the CICS region alters the file and causes this.

dbzTHEdinosauer · Posted: Fri Jun 04, 2010 2:03 am

Robert Sample · Posted: Fri Jun 04, 2010 3:12 am

So you've got a batch process attempting to update a VSAM file at the same time a CICS region has update access to the same file. What enqueue / dequeue method are you using to serialize updates? What are the VSAM file share options? Are you reading the base cluster key or an alternate index key? How many duplicates are allowed for the alternate index, if there is one?

BrantleyL · New User Joined: 03 Jun 2010 Posts: 14 Location: Dallas TX

CICS Guy · Posted: Fri Jun 04, 2010 4:07 am

Strike me as way to little info doled out very selectively.....

Robert Sample · Posted: Fri Jun 04, 2010 6:05 am

dick scherrer · Posted: Fri Jun 04, 2010 6:06 am

Hello,

I believe you're in one of those "the results may be unpredictable" situations.

All of the cics activity is under one "control". The batch job is another and is not aware of everything that is going on elsewhere in cics. The updates in cics may cause something that "was" valid in batch on the last read to no longer be valid for the "next" read. Kinda like batch didn't get the memo. . .

As someone asked earlier - what are the share options?

CICS Guy · Posted: Fri Jun 04, 2010 6:59 am

What process is updating the DB2 table? CICS? Batch?
What process is updating the VSAM dataset? Batch? CICS?
"If the keys match, perform the sync process." Sync what to what? VSAM to DB2 or DB2 to VSAM?

Off the wall, can I assume that the VSAM with AIX is being updated by CICS?
Could not it occur, depending upon the number of buffers available to the base cluster and the AIX, that the AIX could be written to the VSAM dataset while the base clusters may not get there soon enough for your batch program to retrieve them?
Start on the AIX could be successful while the actual base cluster record is not yet there.
VSAM buffers not actually written to the actual DASD have always been a problem with Batch/CICS usage of the same VSAM dataset.

BrantleyL · New User Joined: 03 Jun 2010 Posts: 14 Location: Dallas TX

Thanks for all the thoughts. I was trying to avoid posting the entire program - the whole process is kind of complicated. We are reading based on a partial AIX key.
The file looks sort of like this:
LSKU01-BARCODE01
LSKU01-BARCODE02
LSKU02-BARCODE03
LSKU03-BARCODE04
LSKU03-BARCODE05
Primary key is "BARCODE", AIX is both.

We are trying to move forward from an *OLD* Legacy IMS/VSAM system to one based on DB2. The VSAM file contains SKU information. We need to update (add/change/flag as delete) data on 3 DB2 tables based on updates occuing to the VSAM file. There is too much code around that deals with the legacy stuff, so we are forced to maintain two versions of the data.

During the day, the SKU VSAM file is open to CICS and IS updated. (Share options are (2 3)). The SKU file is also potentially updated by several batch processes at night. ALL of these log requests to perform the SYNC process - which is the last batch process - but can run after the CICS region comes up in the morning. This has not been a problem until the last couple of weeks - when data volume has pushed the batch cycle later.

Robert Sample · Posted: Fri Jun 04, 2010 6:32 pm

Unless you enforce a queuing mechanism, you do not want the batch process running while the CICS region is up. Period. Why?

Possibility 1: your program reads a record that is currently in the second half of a CI. While your program is processing the data, CICS performs a CI split to be able to insert a record. The current record position your program has is no longer valid and a 46 file status code could occur.

Possibility 2: your program reads a record in a CI. CICS does an update to a record in the same CI. VSAM record locking occurs at the CI level, so your program's current record pointer becomes invalid, again resulting in a 46 file status code.

Possibility 3: CA split involving the record your program is using.

and so forth ... basically, unless you use a queuing mechanism to guarantee read integrity of your program's data, your program may get a file status code 46 at any point in time while the CICS region is updating the file.

BrantleyL · New User Joined: 03 Jun 2010 Posts: 14 Location: Dallas TX

Thanks Robert... That explains it. That makes perfect sense.