SA-BCPii Use Cases

Base Control Program internal interface (BCPii) functional characteristics

BCPii is a communication protocol between an application running in a Logical Partition (LPAR) of an IBM Z mainframe (processor) under control of z/OS and the processor attached Support Element (SE). The proprietary protocol does not depend on your network infrastructure and does not use the IBM Z Channel Subsystem. Applications can issue operations management queries and hardware commands to monitor and control the processor and its facilities. The SE either returns immediate command responses or forwards hardware events to registered applications. Local and remote SEs connected to the same processor network can be targeted. In this case, the local SE acts as a gateway for the BCPii request and a Hardware Management Console (HMC) is used to forward the request to the remote SE. The routing HMC also sends data to the local SE of applications previously registered to receive event information.

Available BCPii implementations and general considerations

BCPii is a z/OS provided feature (HWI-BCPii) that offers its APIs to any supported z/OS application environment.

For the SA-BCPii implementation, requests must be issued by an application running under z/OS NetView control and is using System Automation internal services like GDPS, or APIs like ProcOps. Both BCPii implementations use the same services to communicate with the SE. For the IBM Z firmware, the BCPii implementation is transparent. The information source about the processor and its facilities for the SA-BCPii is the Simple Network Management Protocol (SNMP) database, provided by the SE console application. In an IBM Z processor network and on individual processors level, the remote and local BCPii related session workload might vary. It depends on the number of active BCPii applications and the amount of data that flows concurrently. In the BCPii request processing path, there is serialization and queuing in place, where needed. Considering BCPii performance, it is a good practice to keep track of the permanent BCPii sessions and the event traffic they produce.

System Automation functions and solution offerings using SA-BCPii connections

For information about how to prepare and configure the hardware for SA-BCPii connections, see the Planning and Installation manual.

INTERNAL session control transfer between GDPS and System Automation

System Automation automatically starts all defined INTERNAL connections at SA agent start time. If processor related information in a policy data base (PDB) was changed, a refresh with the new build and loaded data at SA runtime might also cause INTERNAL connections to be restarted.

With GDPS 4.2, the solution offerings using the SA-BCPii no longer depend on System Automation to perform the session initialization for processors that are in the management scope of GDPS. Instead, System Automation detects and validates the SA-BCPii connection to the local SE and signals GDPS whether SA-BCPii and the local SE connection can be used. For an SA agent instance, this first step is critical to the overall availability of SA-BCPii. Only specific SA-tasks are authorized to use the SA-BCPii during that time. After SA has notified GDPS about the SA-BCPii status, GDPS can request which of the SA policy defined processor connections it wants to manage and monitor. Later, if GDPS wants to return session management responsibility back to SA, it can issue a message to request this.

The following table lists the messages exchanged between System Automation and GDPS to transfer INTERNAL connection control:

For more details about the messages, refer to the GDPS and System Automation Messages and Codes manuals.