In my reply with the suggested program code that used Area Sweep on the member record type and issued the RETURN... NEXT CURRENCY for each member obtained in the Areas sweep, I said the RETURN does not affect currency. What I meant was it does not affect AREA Currency. That is why this pre-TUNE user-written program method used by many users in the past, did not need to go through any extra code to re-establish Area currency so no members would be missed.
What Chuck did was more efficient than Area sweep because a separate program first walked the specific set occurrence he wanted to Tune (adopt orphans) and wrote a file of member dbkeys in the order they were encountered when walking the set in the Next direction.
The Adoption program then would read the dbkey file, Obtain the member by dbkey, then issue the RETURN... NEXT CURRENCY.
When Chuck tested and said that no orphans were adopted, that seemed odd to me since the Area Sweep method always worked for customers who used it back before Tune Index was created. Further investigation revealed that his method did force adoption of the first orphaned member, but no more.
I reproduced this on my CV with my own small test database.
Since the first one was adopted, at a point when there was definitely no currency of any kind established for the set, I thought I'd try obtaining the orphaned members by dbkey in the reverse order. So I obtain the last member in set by dbkey, issued the RETURN... NEXT CURRENCY and continued this for each member, moving backward.
All orphaned members were adopted.
Chuck changed the extraction program to read the set backward so the member dbkeys would be written to the flat file in reverse order and the adoption program then was successful in adopting all orphaned member records. As mentioned this type of program only clears orphans on the bottom level of the index. TUNE does all levels.
The reason the older Area Sweep method worked was because the members were not being obtained in set order. The order in which they were encountered during Area Sweep was random.
When we Obtain an orphaned member and are forced to use its Index UP pointer to find Next in set, the SR8 pointed to by the UP pointer does not contain the current member's entry so we go through the process of Orphan Adoption until we find the current member's entry and then we can return the Next member's dbkey.
It seems that when the RETURN... NEXT is executed it establishes NEXT currency for the set so subsequent RETURNs are not forced to use the UP pointer to get Next.
Processing the member dbkeys in reverse order forced it each time.
That being said, I would still recommend the IDMS utility TUNE INDEX which we know will clean up all orphans in the index.