Introduction › Modifying CA ACF2 for z/VM

Modifying CA ACF2 for z/VM

There are two types of local modifications you should consider: modifications to standard VM components and standard CA ACF2 for z/VM components.

Existing or Planned Local Modifications

Many sites modify standard VM components (CP, CMS, exits) to provide added functions. You should review these local modifications before you install CA ACF2 for z/VM. In some cases, such as VM logon processing, the local code may perform some security‑related function that is replaced by CA ACF2 for z/VM. In these cases, you can remove the local code. In other cases, the code must remain to perform some needed local function and must reside in the same exit or front‑end the same intercept-point that CA ACF2 for z/VM uses. This requires a decision as to which processing (CA ACF2 for z/VM or the local modification) should come first. CA ACF2 for z/VM should come first because it determines whether the requested function is legitimate. If CA ACF2 for z/VM lets the process continue, the local code is useful.

Local Modifications to CA ACF2 for z/VM

CA ACF2 for z/VM is designed to provide a high level of flexibility to reduce the need for modification. Yet many sites find new ways of using functions and sometimes tailor them beyond what can be done with the provided options. This usually requires producing local code for one or more of the provided exits. Most sites find these modifications can wait until the system is installed, tested, and operational. Most sites install without using the local exits. While you should consider possible local modifications (due to some special naming conventions or transitional implementation plans) and plan for this during installation planning, you can perform the actual coding and activation of these changes after the initial installation and IPL has established the base system.

At What Maintenance Level Should VM Be Operating?

Each distribution tape provides the current requirements for operating system maintenance levels. In general, VM should be at a relatively recent level (maintenance provided by the system hardware vendor applied in six months of the release date). It also should have been running at that level in production a minimum of one week to provide a valid, stable base for code installation and testing.