Gary Van Winkle

01/26/2024 - ANNOUNCEMENT - My webpage was updated today with new content. The webpage is a supplement to other sites offering FREE documentation, tutorials, and code examples for GnuCOBOL users. Visit https://320545.8b.io/ for a list of useful FREE assets. If google takes you to a list of sites click on gnucoboltutorials. My e-mail is on the page. Send me a comment, question, suggestion, or gripe.

June 18, 2022. My website now has documentation and some complete example programs (all in pdf's) for each of the file types supported by GnuCobol. In addition, there are tutorials and documentation for other topics, such as using the Screen Section. Everything there is always free.

Thanks, Ralph. That helps me grasp the structure and the use of the indexes vis-a-vis the data file. I'll check those links next week when I get back on this project. In the meantime, I hope you and Simon each enjoy your weekends. GVW.

I'm still curious about how VBISAM uses the indices, and how the file is organized. My .dat file is in Primary Key sequence (ascending by last name, first name), and I ASSUME that the Primary Index is in the same sequence. I ASSUME that, in most cases, the Primary Index fits in main memory. Therefore, I jump to the conclusion that when I search by Primary Key VBISAM does a SEARCH ALL on the PX to find the name and its data record in .dat. However, how does that "find" work? I'm thinking the .dat...

Having been a user (not an "administrator") of a collection of BISAM (known to IBM mainframe customers as "Basic Indexed Sequential Access Method) files, I can vouch for the frequency of file re-organization required to keep the files usable. There was a constant tuning effort, too, which amounted to adjusting overflow space, moving it to other disk drives, etc. Inevitably, production programs needed to be changed when the file tuning activity became too hectic. IBM's guideline was to perform a batch...

Thanks again, Simon and Ralph. Simon. you win the cigar. I just didn't THINK that the solution would be so straightforward. That's a lesson for me. I obtained the COBOL draft standard, thank you very much. This experience with ISAM makes me believe that, at file creation time, VBISAM creates an index for each key specified, Primary Key and n Alternate Keys. Each Index is sorted by the key values present in the .dat file. The Indices are organized (somehow) in the .idx file. Incidentally, my .dat...

OK. I removed the old READ ISAM-DATA NEXT RECORD and replaced it with READ ISAM-DATA KEY IS ID-ALT-KEY. Got the same identical result. Maybe that's how it's designed to work, I expected the Alternate Key search to be conducted in an Alternate Key Index, STARTing at the first occurrence of the Search Key value, but not reading that record. The READ NEXT loop accesses the first "hit" and each subsequent "hit" until EOF is encountered (Status 10). So far, so good. I'm searching for records containing...

Ralph, here are the statements in the START ........ READ sequence: MOVE ALTERNATE-KEY TO ID-ALT-KEY START ISAM-DATA KEY = ID-ALT-KEY END-START *> START ####### READ ISAM-DATA NEXT RECORD *> READ ######## AT END MOVE "Y" TO EOF-SW END-READ I changed the READ statement to READ ISAM-FILE KEY IS ID-ALT-KEY, but that produced the same result. I can't tell whether all records are actually accessed in both cases. I'd have to test with a pretty big file to detect a difference in performance.