Thanks so much for your reply Johan - that is fascinating for us, as we had generally UNLOAD/RELOADed the entire dependency chain historically. Yes, this does sometimes result in huge database UNLOAD/RELOAD jobs taking hours to execute, however we are fortunate enough that these have always fitted into our maintenance window which in our case is only 12 hours on the weekend.
We are evaluating updating our procedures to reduce this requirement for processing all AREAs. We are also very interested in the new Shadow Re-Org functionality in the hope that it might also alleviate the need for these big jobs, which by necessity have to execute in our Production system.
-------------------------------------------
Original Message:
Sent: May 06, 2026 04:42 AM
From: JOHAN NEVENS
Subject: Re-organising AREAs and dependant AREAs
Hi Mike,
At our site we use the REORG utility to enlarge areas once they have reached a certain utilization rate. When our list of areas is ready to be taken along via a REORG over the weekend, we will first expand this list with dependent areas that meet certain conditions, specifically 2 cases for which we experienced performance issues in the past when we did not include this kind of dependent areas in the REORG. We never include the entire chain of dependent areas, because for some of our larger segments (in terms of the number of record types), this would result in a REORG covering (almost) the entire segment. And I don't know about you, but here in Belgium, there are only 48 hours available during a weekend. :-)
The 2 cases are as follows:
- REORG of an area with a record which is the owner of a VIA set. The member of this set resides in a different area.
- REORG of an area with a record which is the member of a VIA set. The owner of this set resides in a different area and is NOT a CALC record.
To detect these cases, we use a custom-written script that lists these additional areas to be taken along in the REORG based on the dictionary schema records (comparable with the sql script you were referring to) and our internal IDMS database which contains our planned database changes (ao. the area enlargements). We add these new found areas to our list of areas to be enlarged and run this script again and again until the output eventually will be empty.
Kind regards,
Johan
Original Message:
Sent: May 05, 2026 12:04 PM
From: Michael Cairns
Subject: Re-organising AREAs and dependant AREAs
So following up a question that we put to the official IDMS product support channel regarding generating a list of IDMS AREAs that are dependent AREAs when needing to UNLOAD/RELOAD an AREA for the purposes of space management (for us, that's generally enlarging AREAs).
We know that the UNLOAD/RELOAD processing of the BCF utility will generate the 'AREA RECORD DEPENDENCY TABLE' as part of its output if you do not manually allocate all dependant AREAs to the job via JCL yourself. In order to avoid potential performance issues noted in Guidelines for unload/reload where there are dependent areas and/or indexes we have always performed a full UNLOAD/RELOAD on ALL AREAs that were noted as dependent. This of course implies that we must then follow the dependency 'chain', and also UNLOAD/RELOAD all AREAs that are dependent on the dependent AREAs, etc, etc. Sometimes in our system an UNLOAD for a single highly interconnected AREA can result in us UNLOAD/RELOADing a dozen or more AREAs at the same time in order to guarantee complete integrity and avoid updating via cross-area pointers and the possible mentioned performance issues.
Our question is, how do other sites handle this situation? Do you just UNLOAD/RELOAD the single AREA and let the utility update the pointers to the dependent AREAs? Or do you also UNLOAD/RELOAD dependant AREAs together? And if you do them all together, by what method do you determine the entire chain of dependencies?
PS: We have in the past used a trial & error approach to allowing the BCF utility to generate the 'AREA RECORD DEPENDENCY TABLE' and then rerun with the revealed AREAs added, and cycle around this until no more additional AREAs are revealed before we run the job for real. We now also have REXX based tooling that will identify the whole chain if needed. Broadcom IDMS Support were kind enough to provide solid guidance as to how to easily determine the first level of dependencies with an SQL based approach here: SQL script to list cross area sets.
Thanks and regards - Mike
https://knowledge.broadcom.com/external/article?articleId=429333
-------------------------------------------