Interview with Steve Warren, z/OS BCPii technical lead
By Karen Ransom, z/OS BCPii function test lead
I caught Steve Warren between meetings last week and asked him to share a bit of his insight about z/OS BCPii with our readers.
Karen Ransom (KR): Let's start with the basics, Steve. What is z/OS BCPii?
Steve Warren (SW): BCPii stands for "BCP internal interface". It's a programmable interface for authorized applications that allows easy Hardware Management Console (HMC)-like access to the interconnected System z hardware from any z/OS programming environment.
KR: Why are customers so excited about z/OS BCPii?
SW: Traditionally, the link between the operating system and the hardware has been difficult to access and understand. BCPii opens up the hardware to the 'eyes' of z/OS authorized programs.
Installations use the HMC and the Support Element (SE) to manage hardware objects such as CPCs, LPARs, capacity records, and activation profiles. But for a long time, z/OS customers have wanted a way to perform tasks normally accomplished from the HMC or SE GUIs in a more controlled and automated fashion. Using BCPii, an application can perform the same types of tasks as a user of the HMC GUI. For example, assuming it has the required authorization, an application can do things like activate and IPL an LPAR, modify values in an activation profile, and change processor weights on a live LPAR.
KR: Sounds great, but is BCPii easy to use?
SW: Yes, it is. We went to great lengths to make the interface easy to use. BCPii attempts to use terms in the same way the HMC uses them, making the programming experience intuitive. And in the upcoming V2R1 z/OS release, we take 'ease of use' to a new level by introducing our new REXX support. Whipping up a REXX exec that uses BCPii is simple. We even support running REXX execs in a number of different REXX programming environments, allowing additional flexibility. A system programmer should be able to have a working BCPii application in no time flat.
KR: Wow, that does sound easy, but what does a customer have to do to install BCPii?
SW: BCPii installation requires just a few steps, and several folks are involved. First, the hardware engineer needs to perform a couple of easy steps on each SE where BCPii access is desired. Second, the security administrator needs to define BCPii RACF profiles to grant access to users for specific hardware resources. Third, the z/OS system programmer can optionally set up a few BCPii controls. That's it!
KR: So, how are customers responding to BCPii?
SW: It's been interesting to see how many customers have immediately shown interest in BCPii. When we were designing BCPii, we expected that Independent Software Vendors (ISVs) would be the primary consumers of our services. While a number of ISVs have incorporated BCPii in their products, customer use has far exceeded use by ISVs. It has also been interesting to see the creative ways customers are using the BCPii APIs -- more ways than we ever anticipated!
KR: Yes, that is really interesting! But what about security? How does BCPii address everyone's security concerns?
SW: Of course, folks are always concerned with the power of the BCPii APIs and want to make sure that they're not opening a security hole by enabling BCPii. But once they see that the BCPii API calls are truly secure, and that access can be controlled, they embrace BCPii. BCPii provides granular access control by allowing the security administrator to grant access to specific users for specific hardware resources.
KR: What if a customer isn't quite ready to code their own BCPii applications?
SW: Even if a customer is not interested in creating their own BCPii applications, they can still benefit from the power of BCPii by exploiting z/OS components and ISV solutions that use BCPii. For example, Parallel Sysplex uses BCPii in their System Status Detection (SSD) partitioning protocol, introduced in V1R11. Many customers are now choosing to use SSD because it makes dealing with a 'sick' system in a sysplex much simpler and faster. SSD auto-discovers the status of failed systems in a sysplex during sysplex recovery processing. If it determines that a system is really dead, it removes the system from the sysplex automatically. All using BCPii! SSD is recommended by IBM in the Parallel Sysplex "Best Practices."
KR: I know you're busy, so just one last question. Where can our readers find out more about BCPii?
SW: Easy one! They can check out the Base Control Program internal interface (BCPii) topic in z/OS MVS Programming: Callable Services for High-Level Languages. Here's the link: http://publibz.boulder.ibm.com/epubs/pdf/iea2c171.pdf
If you have any additional questions for Steve, just add a comment below!
Check out other BCPii posts on the Mainframe Insights blog:
Steve Warren is a Senior Software Engineer and the overall technical lead for BCPii. He has worked at IBM for 24 years, focusing on z/OS development and FCT in APPC/MVS, System Logger, Websphere and BCPii. Steve likes to spend time playing sports and is also heavily involved with music in his church as both worship leader and band member.
Karen Ransom is an Advisory Software Engineer and the function test lead for BCPii. She has 29 years of z/OS development and test experience, spanning the IPCS, SLIP, GRS, Parallel Sysplex, and BCPii components. She enjoys gardening, and walking or biking the beautiful trails in the scenic Hudson River Valley of New York State.