Problem when VSAM is empty

Bharanidharan · Posted: Mon Jul 24, 2006 4:49 pm

I encountered a trouble today with KSDS that seems strange.
I have an user program that reads a KSDS file, writes to flat file and deletes the record from KSDS (more precisely, it is done in assembler via GET & ERASE RPL macros).
1. When I delete-define a KSDS and use it in this user program, it doesn't perform end-of-file routine as I expected. When I try to browse it in File-Aid, it doesn't open the dataset and shows 'Empty dataset' instead. When I tried to VERIFY it, RC was 12.
2. Now, I inserted a blank record in the file (thru File-Aid) and ran it thru my program; program deleted the record from KSDS correctly.
3. When I browsed it in File-Aid, it opens the browse panel showing ***** TOP OF DATA **** and ****** BOTTOM OF DATA ******. VERIFY gave RC as 0.
4. This file, when run through my program again, my program performed end-of-file routine.

Now my question is: what is the difference between the state of the KSDS file in steps 1 and 3? My guess is that no EOF markers would be created automatically when a file is delete-defined, but would be introduced when single record is inserted (and deleted).

Hanfur · Active User Joined: 21 Jun 2006 Posts: 104

This is because the HURBA would be zero when a new VSAM file was initially created and subsequently when record was inserted to it would change this value.

VSAM identifies as empty file when HURBA is 0.

HURBA contains a pointer which points to the last address location of a record in VSAM.

-Han.

Bharanidharan · Posted: Wed Jul 26, 2006 8:19 pm

I agree, but if VSAM is considered empty for HURBA=0 (initial state after creation), my process must've recognized the HURBA as 0 and should've taken the EOF path, but it didn't; in fact, it didn't even acknowledge that it couldn't access any records nor LURBA/HURBA. Instead, it took the VSAM as empty only when HURBA was not 0 (set to some value after insertion and deletion). Is this discrepancy explicable?

Hanfur · Active User Joined: 21 Jun 2006 Posts: 104

Bharani,
As I said earlier HURBA value would be intially zero;at this stage VSAM opening in INPUT mode wont be successfull.That could be the reason when u browsed at first time u got the FILE EMPTY message.

But when tried to INSERT record in to VSAM ,HURBA value was set with address location of record just inserted.Though u deleted data from file the HURBA still doesnot reset to ZERO but was populated with some other value as HURBA contains the last address to the last location of in CA l which is not zero.

This could be the reason u were abale to BROWSE the file though no data is there and an EOF is encountered in ur program.

-Han.

Bharanidharan · Posted: Fri Aug 04, 2006 10:12 pm

Thanks for the reply Han. It took some time to figure out the problem, which I am presenting here.
When a KSDS is allocated for the first time, HURBA always would be zero while HARBA (high allocated RBA) would have the value of last extent + 1. VSAM manual says a file cannot be opened in any of the input modes if HURBA = 0. When it happens, IDCAMS routine would return non-zero return code; it inherently examines the values of HURBA (for data or index components) and hence gives an appropriate return code.
Unfortunately, this is not what happens when SVC 19 is issued through MVS OPEN macro. Control is directly passed on to SMS, which would search for the dataset, verify the type of file (in this case VSAM), and verify the suitability of the access method for the mode requested for the file; if all is well, it is returning a zero return code. Even TESTCB on the opened datase passes because of the earlier handling of the file by SMS. If a GET is issued against a newly allocated file which is set open (via OPEN), SMS posts non-zero return code.

We had this fixed now. Thanks for shedding some light on this one.