As you describe your problem in greater detail, it appears this would likely be best served by an Adabas specification of a non-reusable ISN.
The two potential problems you mentioned were:
1 You wanted an integer that is always incremented by one. Non-reusable ISNs provide such a sequence of values.
2 You wanted the values to be unique. ISNs are unique.
You stated that records do not get deleted. Is this from the “data file” as well as the table file? If so, there would be no problem with a sparse ACT.
How will the “primary key” be used? It is quite apparent that the primary key has nothing to do with the business. It is supplied by the program/database, not business logic.
I am guessing now, but I imagine you might be using the primary key to logically link two or more Adabas files where there is no business key that could be employed.
A typical use might involve a search (FIND) on one file that identifies one or more records. Then, you wish to access “related” records on another file. ISNs would serve such a scenario without requiring playing games to ensure uniqueness (z.b. locking records in the table file) .
Just out of curiosity, what were your table file records going to look like? Would they just have a field that would be the unique ID and an ISN from another file? If so, by using non reusable ISNs you can eliminate the table file entirely and logically link data files without extra accesses to the table file (since it would not exist).