BC1JACMO is an ACMQ maintenance job invoking the BC1PACMO Utility, which is intended to reorganize your ACMQ ROOT and XREF datasets.
This tech note provides background information of this Utility and the ACMQ datasets.
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).
You move both elements 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 it 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 your 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.
A few other frequently asked questions:
Q: Can I run BC1PACMO while processors are running and component lists are updated?
A: Yes, ACMQ updates (processors) and ACMQ reorganization (BC1PACMO) can run concurrently. Both processes use ENQ to ensure file integrity.
Q: Should I let Endevor reorganize its files automatically or should I schedule regular ACMQ updates manually?
A: The automatic reorganization after 5000 records have been added, has the advantage that it reorganizes the files when needed. The small disadvantage is that the automatic reorganization can run at times when the files are heavily used, and can then cause delays. It is therefore recommended to run manual BC1PACMO jobs at regular intervals outside peak hours, usually between once a day and three times a day as well as activating the automatic reorganization. Remember that a badly organized file will affect performance.
Note that a new option, ACMQ_REORG_BY_WTO, will become available per Problem record 6230. This will instead of the automatic reorganization as specified in the AUTO_ACMQ_FILE_REORG, issue a WTO that will enable one to schedule a reorganization job at a suitable time.
An example of the report the BC1PACMO Utility produces:
LAST REORGANIZATION DATE: 18 AUG 2008 ROOT DSN: PUBLIC.P4489.ROOT STATISTICS: BEFORE AFTER BLOCKS 113 112 TOTAL RECORDS 3577 (97%) 3525 TYPE 1 2256 2213 TYPE 2 1321 1312 TYPE 3 0 0 TYPE 4 0 0 TYPE 5 0 0 TYPE 6 0 0 DELETED 0 0 ORPHANS 52 0 MODE OPT OPT XREF DSN: PUBLIC.P4489.XREF STATISTICS: BEFORE AFTER BLOCKS 69 63 TOTAL RECORDS 43380 (92%) 42602 Explanation: BLOCKS : number of Physical 4K records in the VSAM LDS file (ROOT/XREF) Total records : number of Logical records in the VSAM LDS files (ROOT/XREF) Between parenthesis, the percentage of records in the sorted section of files. Type 1 : ACM-Related FOOTPRINTed Components Type 2 : ACM-Related Non-FOOTPRINTed Components Type 3 : User-Related FOOTPRINTed Components Type 4 : User-Related Non-FOOTPRINTed Components Type 5 : User-Related OBJECTS Type 6 : User-Related COMMENTS Deleted : Number of logically deleted records in the root file (component removed from ENDEVOR, or moved to another inventory location)
This report shows that the previous reorganization date was aug 2008.
The percentage of 97 is the ratio of records representing existing Elements and related Components, compared to the total records, in the ROOT.
In this case the difference was due to the 52 orphaned records.
The percentage of 92 in the XREF is the ratio of existing component relationship records compared to the total.
The remaining records after reorganization are again placed in sort order to optimize search performance.