Auto Resolve
When area audit is initiated with the Auto Resolve option, it generates and submits stage, recompile, and relink jobs to fix the out-of-sync errors it detects. Components that are rebuilt or newly created by auto resolve are put in the area libraries for the release area being audited.
Note
When auto resolve submits recompile or relink jobs for components in other areas and in baseline libraries, new build components are written to libraries in the audited area.
Auto Resolve Scope
When you request auto resolve, you have three choices for the scope of auto resolve processing:
-
ALL - Submit stage, recompile, and relink for all out-of-sync errors that can be resolved.
-
SUB - Submit stage, recompile, and relink for subprograms only.
-
COM - Submit stage, recompile, and relink for statically linked composite load modules or load that is otherwise fully resolved and executable.
Auto resolve is unable to create JCL for build jobs and submit them in a series of dependent jobs that guarantee that the hierarchy of subprogram and statically linked composite loads will be built with no remaining out-of-sync errors.
If you know that you have a very simple structure in your release area, you can request auto resolve with an ALL scope.
However, it is usually most efficient to run auto resolve with a SUB scope to build subprogram components first, then run area audit again with an auto resolve scope of COM to build composite components.
Keeping Package and Area Libraries Aligned
Release management centers on the contents of area libraries. Package staging libraries feed components into the release process with check-in to a starting area, but the objective of release area auto resolve is to fix out-of-sync problems in area libraries.
However, auto resolve keeps attached packages and their contents aligned with the contents of the area being audited. Area components that must be restaged are marked INCOMP in the originating package until the build process completes successfully and the build products are copied to the package staging libraries as well as area libraries. If recompiles or relinks are required, they are also marked INCOMPL in an attached package until the build process completes successfully and new components are copied to package staging libraries and area libraries, and they are marked ACTIVE in the package.
Designating a Preferred Package for Autoresolve
You may wish to perform active development in one release feeder package while reserving a different one for all baseline, prior release recompiles, and relinks generated by an audit autoresolve.
If a component already exists in the audited area and is being rebuilt in place, the feeder package used to synch with the build must always be the one from which the component was checked in (or with which it was originally synched on the autoresolve that generated it in the first place). The need to choose a feeder package for autoresolve only exists when a component is being brought into the area for the first time, e.g. recompile/relink from baseline/prior release.
If no preferred package is indicated, the algorithm for choosing a package to synch with new components that are pulled into the release area uses the application feeder package in DEV status with the latest install date, or the highest number if install dates are equal. The audit program (CMNRA000) will make use of the following sysin parameter to indicate such a preferred package:
ARSPKG=<pkg name>
You can specify as many of these as you need but if more than one is presented for the same application, only the last one will be used.
If you submit the audit from the ISPF client, you will be given the opportunity to specify auto resolve preferred packages as part of that dialog.
CMNRMAUD Release Area Audit
Command ===>
Release . . . . . . . . . SDJAN221
Area . . . . . . . . . . UNIT
Ignore higher areas . . . NO (Y/N/C)
Enter "/" to select option
_ Include related applications
/ Auto resolve out of synch conditions using scope A (A/C/S)
/ Specify preferred packages for autoresolve
Job statement information:
//JOBNAME JOB ,'ACCT',CLASS=A,TYPRUN=HOLD,
// MSGCLASS=X,NOTIFY=&SYSUID
//*
/*JOBPARM S=XXXX
CMNRMAUP Autoresolve Preferred Package List Row 1 to 4 of 4
Command ===>
Scroll ===> CSR
Release: SDJAN221 Area: UNIT
Package Title
S STEV001578 autoresolve package for release SDJAN221
STEV001579 feeder package for release SDJAN221
STEV001581 feeder package for appl STEV to release SDJAN221
S STV2000295 feeder package for appl STV2 to release SDJAN221
********************** Bottom of data ********************************
<listCount> </listCount>
<arsPreferredPkg> </arsPreferredPkg>
<arsPreferredPkg> </arsPreferredPkg>
<arsPreferredPkg> </arsPreferredPkg>
Note
Your selection is stored in the definition of the release and will be re-used in future audit submissions. Once the preferred packages are set, you only need to set them again if you wish to change them.
Test Area for Auto Resolve
After package components are checked in to a release, the components in the package can be altered, depending on area rules. To prevent auto resolve from overlaying package components that have been changed or creating orphans when package components have been deleted, Test Area is automatically executed in the area before a request for auto resolve is executed.
If test area fails, the area audit job fails with RC=12 and the following messages are displayed:
CMR1005I - Autoresolve requested.
CMR1004A - Audit failed - Audited area must pass TestArea function if autoresolve is requested.
CMR1506I - Release R041218/ACCTPAY and package components do not match.
It is particularly important that you execute RUNSTATS after the initial loading of the tables. If Db2 chooses not to use the indexes to access the tables, performance may be unacceptable.