This document summarizes the PAC/PAA functions that address the control issues discussed in section Application Control.
| Where is the source code for an object? | PAC stores all source code in the protected ACF system file. |
| Do the source and executable code match? | PAC automatically synchronizes the source and executable code for each object version. |
| What other objects do an object use? | PAC lists all Natural and Predict objects that a specified object uses. |
| Which version of an object does a calling program use? | PAC lists the name, object type, and version number of each object used by the calling program. |
| What is the current version of an object? | You can view the version history for an object. PAA lists the current versions of objects in a production status. |
| How are obsolete objects handled? | You can use a PAC archive facility to unload objects to storage media, purge them from the PAC-controlled environment, and restore them if necessary. From a production status, only superseded objects can be archived. With or without first archiving them, you can purge objects from a status or from the PAC-controlled environment by migrating them to a retire status. |
| How are the operating environments defined? | In PAC, you specify the location of the Natural library, Predict file and foreign object dataset for each status (phase) of an application life-cycle. You can define multiple environments for each status type except Control, Archive and Retire. |
| What environments are defined for an application? | You can view all statuses to which a specified application is linked. |
| What is the location of a specific environment? | You can view the system file assignments for the linked status. |
| What is the life-cycle of a specific application? | The life-cycle is the structure of linked statuses for an application, along with the valid migration paths among them. You can view all linked statuses and migration paths for a specified application. |
| Who can authorize migrations between two environments? | Valid authorizers are specified in the migration-path definition. You can view the valid authorizers for the migration path. |
| How do you handle migrations when the origin and destination environments are heterogeneous? | PAC operates independently of the operating system, TP system, and DBMS (PAC supports ADABAS, DB2, and VSAM files). |
| How do you enforce migration and promotion procedures? | Standard migration and promotion procedures are defined and enforced in the migration paths, migration events, and jobs. The PAC administrator controls who can define migration paths; migration paths specify authorizers; and no unauthorized migrations can be made. |
| How do you ensure that the correct object version is implemented and referenced? | By default, PAC migrates the latest object version in the origin library. To ensure that the latest version is the correct one, you can display the source code for the version or compare versions. |
| How do you compile an object referencing one set of databases and files and execute it referencing a different set? | Assign a file translation table to the application status link for each status in which you want to execute the object. When you migrate the object, PAC dynamically recompiles it to reference the correct database and file numbers. |
| How can you recover an object that is accidentally overlaid? | PAC stores each object version in the protected ACF system file. If an object in a status library is overlaid, it can be reloaded. PAA backs up a production object before replacing it; you can back out the job that replaced it and restore the earlier version. |
| How is implementation controlled? | All PAC migrations require authorization. The PAA administrator can predefine production applications and control load jobs. |
| Where is an object implemented? | PAA displays the production library, database number, file number and dataset for any object in a PAA-controlled production environment. |
| How is implementation of production objects tracked? | PAA automatically tracks migrations of objects into production. PAA provides audit reports and supports user-written reports via use of the supplied APIs. |
| How do you recover when an implemented object causes system problems? | The PAA administrator can backout a load job and automatically restores an object version replaced by the load. You can also reload earlier versions. |
| How is maintenance tracked and controlled? | To change an object, you must make an authorized migration to a development or maintenance status. PAC logs all check-outs and check-ins (migrations to and from a maintenance status), which can be audited and disallowed. Maintenance requests can be linked to migration events and logs. |
| Who is changing an object? | The change control log for the object shows all users who have checked out the specified object. |
| How are concurrent changes handled? | By default, PAC warns a user who checks out an object that is currently checked out by another user; concurrent check-outs can be blocked. When several users check out an object version concurrently, each check-in of the object is given a new version number. |
| How are related problems grouped? | You can define a single maintenance request for related problems and assign it to multiple migration events; thus, you can view all migrations to and from maintenance for the related problems. Maintenance requests can span applications. |