Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Problem when VSAM is empty

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> DFSORT/ICETOOL
View previous topic :: :: View next topic  
Author Message
Bharanidharan

New User


Joined: 20 Jun 2005
Posts: 86
Location: Chennai, India

PostPosted: Mon Jul 24, 2006 4:49 pm    Post subject: Problem when VSAM is empty
Reply with quote

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).
Back to top
View user's profile Send private message

Hanfur

Active User


Joined: 21 Jun 2006
Posts: 104

PostPosted: Wed Jul 26, 2006 2:17 pm    Post subject: Hi
Reply with quote

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.
Back to top
View user's profile Send private message
Bharanidharan

New User


Joined: 20 Jun 2005
Posts: 86
Location: Chennai, India

PostPosted: Wed Jul 26, 2006 8:19 pm    Post subject: Re: Problem when VSAM is empty
Reply with quote

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?
Back to top
View user's profile Send private message
Hanfur

Active User


Joined: 21 Jun 2006
Posts: 104

PostPosted: Fri Jul 28, 2006 10:27 am    Post subject: Hi
Reply with quote

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.
Back to top
View user's profile Send private message
Bharanidharan

New User


Joined: 20 Jun 2005
Posts: 86
Location: Chennai, India

PostPosted: Fri Aug 04, 2006 10:12 pm    Post subject: Re: Problem when VSAM is empty
Reply with quote

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.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> DFSORT/ICETOOL All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts VSAM Space Allocation mrgnndhmk JCL & VSAM 7 Sat Apr 22, 2017 12:42 am
No new posts Strings with double quotes having pro... raja Arumugam All Other Mainframe Topics 11 Thu Mar 30, 2017 10:34 am
No new posts Problem reading GTF trace output danik56 ABENDS & Debugging 7 Thu Mar 16, 2017 1:02 pm
No new posts Updating a VSAM file with DISP=OLD sheersh JCL & VSAM 8 Tue Mar 14, 2017 6:14 pm
No new posts SORT VSAM file with each field one by... maxsubrat DFSORT/ICETOOL 6 Tue Mar 14, 2017 1:07 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us