Re: RRN Reletive record number question

+1 Holger!


There was a time when the RRN was used to make things like a bill-of-materials - a linked list of things, and the RRN of the next item in the list was stored in a row. I think MAPICS did that - at least, that's the example of an application that relied on preserving RRNs.


Here are reasons not to say *YES on REUSEDLT, as listed in the 7.5 documentation -


Note: Because of the way the system reuses deleted record space, the following types of files should not be created or changed to reuse deleted record space:
* - Files processed using relative record numbers, and files used by an application to determine a relative record number that is used as a key into another file
* - Files used as queues
* - Any files used by applications that assume new record insertions are at the end of the file
* - When DB2® Symmetric Multiprocessing is installed, files on which you expect to have parallel index maintenance performed when rows are updated, inserted, or deleted
Cheers
Vern


On Thu, 4 Apr, 2024 at 12:51 PM, Holger Scherer <hs@xxxxxxx> wrote:


To: midrange systems technical discussion; midrange-l@xxxxxxxxxxxxxxxxxx

do not rely on RRN or their order at all.
Do rely on unique keys and time stamps if ordering is needed.

-h

------ Original Message ------
From "Timothy Feldmeier" <Timothy.Feldmeier@xxxxxxxx<mailto:Timothy.Feldmeier@xxxxxxxx>>
To "MIDRANGE-L@xxxxxxxxxxxxxxxxxx<mailto:MIDRANGE-L@xxxxxxxxxxxxxxxxxx>" <MIDRANGE-L@xxxxxxxxxxxxxxxxxx<mailto:MIDRANGE-L@xxxxxxxxxxxxxxxxxx>>
Date 04.04.24<http://04.04.24>, 17:09:37
Subject RRN Reletive record number question

I know the RRN can change when running a reorg, as it will reuse deleted records etc... My question is - would the order of the RRN every change for a record.
This would allow a program to keep the RRN order to be always reliable.