Re-organising AREAs and dependant AREAs

[Michael Cairns]

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

-------------------------------------------

[JOHAN NEVENS]

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

-------------------------------------------

[Michael Cairns]

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.

Many regards and thanks - Mike 

-------------------------------------------

[Denise Basore]

Once, long ago, we performed an unload/reload on a CALC parent and left
out the VIA children. It caused major performance problems because the
clustering was now compromised and we had to redo the entire process
including the children.

From then on, when unloading/reloading a CALC or VIA parent, we include
all the VIA children. CALC children don't matter because they use the
CALC algorithm for clustering.

Every case is not the same. Some results depend on the logic used to
read/update records. If you have historical children that are just
stored and hardly ever read, it may not matter.

Denise Basore
Hera IDMS Support
1-514-600-0641, ext 408
1-855-600-0641, ext 408

[Michael Cairns]

Thanks for this detailed response Denise, that's very useful information to understand the potential impact of not re-organising the dependent AREAs, especially as only a year or so in I am still somewhat of an IDMS newbie and still getting my head around how these set relationships work in practice.

Many regards and thanks - Mike 

-------------------------------------------

[Sandra Mabena]

When executing an UNLOAD-RELOAD on an area, we simply include the impacted areas in the jobs, but we do not perform an UNLOAD-RELOAD on them. As you mentioned, including more areas may have a ripple effect and further require you to include more areas.  Depending on the database design, this may eventually include all areas in the segment.

------------------------------
Regards
Sandra Mabena
------------------------------