Migrating from LPAR Management to ProcOps

The LPAR Management function is no longer supported starting from Z System Automation 4.3. When you migrate to this new release, it's mandatory to complete the following steps for all LPAR Management function exploiters.

LPAR Management function dropped

The LPAR Management function allows users to exploit the SA-BCPii connection protocol for ProcOps command ISQCCMD, without having to fully configure or start the ProcOps function itself. Only a subset of the common commands is usable; all commands with asynchronous responses are not supported. The SA-BCPii INTERNAL sessions are shared between GDPS or System Automation's optional Sysplex automation.

With System Automation 4.2, the hybrid-SNMP support was introduced. This feature enabled the non-shared SA-BCPii communication in ProcOps. Automation scripts originating from LPAR Management can migrate and use the full set of ProcOps common commands if ProcOps is configured and active. With System Automation 4.3, the ISQCCMD LPAR Management ProcOps emulation layer is no longer available. Applications using this layer must migrate to ProcOps.

Migrations steps

For ProcOps, you need to change the processor entry definitions in the PDB to support hybrid-SNMP and assign target systems to processor LPARs to make the ProcOps data model work. You need to complement the Support Element API settings of the affected processors with information about the additional BCPii session. In addition, you need to migrate your automation routines using the provided sample script.

  1. Identify the affected processors of your LPAR Management applications. These processors have the INTERNAL protocol specified in the PROCESSOR INFO policy of their PDB PRO entries.
  2. Change the Support Element API settings of the identified processors. Follow the procedure for SNMP over BCPii communication as described in Enable the SE API, Set the Community Name and the SNMP Information. Make sure that the added community name is in uppercase.
  3. Change the following PROCESSOR INFO policy definitions of the PRO entries in the Customization Dialog.
    • Connection Protocol: Add SNMP.
    • Community Name: Add the community name from step 2.
    • ProcOps Target HW Name: Add the target hardware name. It must be different from the PRO entry name.
    • SNMPv3: Add NO.
    • Path Poll Option: Add CONN (recommended).
    • Path Poll Frequency: Add 30 (recommended).
    • Path Poll Retries: Add 2 (recommended).
    • Command Retries: Add 10 (recommended).
    • Command Retry Wait Time: Add 1 (recommended).
    • TCP/IP Address/Hostname: Add ISQET32. This definition enables the hybrid-SNMP redirection over SA-BCPii.

    After a PDB build, your SOCNTL/ACF has the changed processors in the ProcOps data model. They are known to ProcOps with their target hardware names (THW).

  4. In the processor's LPARS AND SYSTEMS policy, define the set of LPARs you want to control with ProcOps and assign the already defined target systems to each LPAR.
    If there is no target system definition in your PDB to be assigned to an LPAR, you need to define the new system using the SYS entry type. For new ProcOps target systems without applications being managed by the System Automation SysOps component, the minimum required policies are SYSTEM INFO, TARGET SYSTEM INFO, and PROCESSOR.
    1. When defining the new system, specify the required definitions for fields Entry name, Operating system, and Image/System name (recommended to define the same name as for the entry name).
    2. In the new system's TARGET SYSTEM INFO policy, specify the following minimum required definitions:
      • Initialize target system
        • Add YES if you want to start the connection automatically each time ProcOps is started with the ISQSTART command.
        • Add BYPASS if you don't want to start the connection automatically. In this case, you need to manually start the connection using the ISQXDST dialog or the ISQXIII command.
      • Target time same as host: Add YES (recommended).
    3. In the new system's PROCESSOR policy, assign the intended processor/LPAR to this target system.

    After a PDB build, your SOCNTL/ACF has the target systems assigned to the appropriate processor/LPAR in the ProcOps data model. Note that ProcOps internally depends on the association between target systems and processor/LPAR definitions even if ISQCCMD itself allows to specify a THWname or a THWname.LPARname as the command target.

  5. (Optional) Define the ProcOps function as an application, so that SysOps can control the availability of the ProcOps focal point. You can adapt the sample application PROCOPS, which contains the startup and shutdown commands and some other necessary definitions. It can be imported from the *PROCOPS add-on policy.
  6. Define a facility class profile HSA.ET32OAN.ISQET32 for application resource ISQET32 and grant NetView READ access to it in RACF. For more information, see Allowing NetView to Use the BCP Internal Interface.
  7. Migrate your LPAR Management application scripts using the sample member INGEI008.

    With LPAR Management, the processor_entry_name or processor_entry_name.LPAR name can be used to specify the target destination of an ISQCCMD request. This is not supported in ProcOps. Instead, the target system name, the THWname or the THWname.LPARname from the ProcOps data model has to be used.

    With System Automation 4.3, a new sample member INGEI008 is provided in your SINGSAMP library. This REXX routine illustrates how you can use the DISPACF command to convert a processor_entry_name to the associated ProcOps THWname. In addition, ProcOps services are called, which helps to determine the current ProcOps configuration and the THWname connection status.

  8. ProcOps requires general-purpose and processor-related autotask for its operation. Sample member AOFOPFPO provides the NetView task definitions for the general-purpose autotasks, 40 message monitor tasks (MMT), and 40 target control tasks (TCT). At runtime, each processor has one message monitor task (ISQCMxxx) and one target control task (ISQBTxxx) assigned. The number of MMT and TCT tasks that are predefined in AOFOPFPO can be larger than the number of processors defined in your PDB, but not less.
    Note: When autotasks are added or deleted, ensure that relevant entries are also updated in the INGESAF sample.

After you complete the migration and on condition that ProcOps is active, you can use the ISQCCMD common command interface to control processors, LPARs, or target systems.