search cancel

Purpose and function of the Endeovor ACMQ cleanup utility BC1PACMO.

book

Article ID: 50563

calendar_today

Updated On:

Products

Endevor Software Change Manager (SCM) Endevor Software Change Manager - Natural Integration (SCM) Endevor Software Change Manager - ECLIPSE Plugin (SCM) Endevor Software Change Manager - Enterprise Workbench (SCM)

Issue/Introduction

What is the purpose of running the BC1JACMO Utility 

 

 

Environment

Release:  18.0  18.1 
Component: Endevor 

Resolution

The primary function of BC1PACMO is to reorganize the contents of the ACMQ files. When Endevor actions are executed and new component lists are built and old ones become obsolete, Endevor adds records to the ROOT and XREF data sets and marks certain XREF records as unused. The new records are appended at the end of the files in unsorted order. While searching through ACMQ, the search through a sorted area takes only a few instructions to find the right record, while searching through the unsorted area is much less efficient.  This is the reason why re-sorting on regular intervals is advisable.

There is a secondary function in ORPHDEL (when run without PARM=VALIDATE).

Consider the following example:

PROGRAM COBOL1 is in ENV1/STG1 and uses COPY2, also from ENV1/STG1.
ACMQ will have ROOT records for both COBOL1 and COPY2 (referencing ENV/STG1).

When both elements are moved to ENV1/STG2 using the generate processor. 
ACMQ will add the NEW references of COBOL1 and COPY2 (now in ENV1/STG2) to the ROOT file, and it will invalidate the (XREF) reference between COBOL1/COPY2 of ENV1/STG1.
 
The next run of BC1PACMO will recognize that the records for COBOL1 and COPY2 in ENV1/STG1 are no longer used, and will remove them from the ROOT file. The invalidated reference between them in the XREF file will also be removed.
Under no circumstance will BC1PACMO touch the MCFs and Element Catalog; it will just look at the contents of ROOT and XREF and remove whatever is no longer used and SORT the file contents in the correct order.

So what does PARM=VALIDATE add to this?

When running BC1PACMO with this parameter, Endevor will validate for each PARENT in each relation (COBOL1/ENV1/STG2 in our example), that it still exists in Endevor. There have been cases where the ACMQ files contained references to elements in inventory areas that no longer existed. This may have happened when a delete processor got cancelled prior to the execution of the ACMQ updates, or for example when an entire MCF got disconnected from the C1DEFLTS table.

For clients in situations like these, we added the validate option. It allows ACMQ to validate that the data it contains is still referenced in Endevor. Anything that is no longer referenced will be deleted from ACMQ.

Therefore, the BC1PACMO run without PARM=VALIDATE should be the normal (daily) run. It is faster than with PARM=VALIDATE and there usually should be no reason to suspect that your ACMQ data has gone out of sync with your component lists.

But in case you do have a suspicion, or if you want to check occasionally whether your ACMQ data is indeed in sync, you may want to run with this option every now and then.

If the run with PARM=VALIDATE regularly reports REMOVED REFERENCES, then there is reason for some concern and you should try to find out why these ACMQ references were not cleaned up during normal processing, in order to find out if your processes can cause ACMQ/Endevor de-synchronization.

ACMQ contains data that is a subset of data from your component lists. BC1PACMO will ONLY reorganize this copy of the data, and never update your MCFs, ELMCATL, or your Component Lists themselves.