The Natural manual states that the content of the multi-fetch buffer is released when the database loop is terminated. Then a few statements later, it states that "the program does not receive “fresh” records from the database for every loop, but operates with images retrieved at the most recent multi-fetch access. My client has noticed if he runs scans on the same set of records one after the other without terminating the program, the 1st scan takes considerably longer than the second one. .
If you specify a multi-fetch factor of 10, Adabas retrieves 10 records and sends them back in the Record Buffer (instead of the normal single record in the RB). Natural presents the 10 records to your program one at a time - one per processing loop iteration. In the time that it takes to process those 10 records, one or more of them may have been modified in the database by another user. Your program will see the records form the RB, not the updated versions in Adabas.
If program logic escapes the loop before all 10 multi-fetched records are processed, the unprocessed records are ignored.
The contents of a Record Buffer are unique to a user/command combination and are completely independent of any other Adabas user. (Each batch job or terminal session would be considered another user.) The RB of one instance of a program has no effect on the RB contents of a second instance.
What your user is experiencing is the result of the Adabas Buffer Pool. The first program instance reads some records (multi-fetched or not). This means that Adabas has performed IO to retrieve data blocks from disk into its Buffer Pool. The second program instance wants the same records. Adabas finds that their data blocks are already in the Buffer Pool, so the second program does not experience the wait times for IO that the first instance did. The second instance is faster because it benefits from the “effort” of the first instance.
Thank you for the reply!