Redhat defines Infrastructure as Code (IaC) as the managing and provisioning of infrastructure through code instead of through manual processes. It emphasizes that this code should be maintained in a source code library as any other code to have it under version control. The code can then be used to provision infrastructure via automation. It is usually provisioning virtual infrastructure as physical devices still need to be installed and cabled manually.
IBM Z server are fully virtualized server and z/OS is an operating system running in a virtual environment on that server. IBM Z server and z/OS have been introduced at times when automation was not yet a theme and most customers still maintain their configuration manually. This leads to many different configurations without standardization. This article discusses IaC for z/OS using Hardware Configuration Definition (HCD) as an example.
HCD is the z/OS component that is used to define hardware I/O configuration of your IBM Z environment and the corresponding z/OS software configuration. Hardware configuration comprises the physical and virtual devices, how they are cabled and connected, and the virtualization to virtual servers named logical partitions (LPARs). Software configuration tells the operating systems about these devices and defines operational requirements and physical parameters and features. Maintaining I/O configuration is a typical task done manually by most customers. How could this be handled as code?
When HCD was invented, it was supposed to replace I/O Configuration Program (IOCP) and MVS Configuration Program (MVSCP). Both programs were meant to describe hardware and software configurations using text decks. The text decks contain I/O definitions in a declarative language, hence already represent code. Such code could be maintained in a source code library and you were done.
IOCP decks and MVSCP decks are not used to often anymore. HCD is still able to import (migrate) IOCP and MVCP definitions into an I/O Definition File (IODF). An IODF is HCD's repository for storing I/O configurations data in binary form. Hence maintaining an IODF in a source code repository is not appropriate. Also, to ease definitions of data center configuration and allow to create matching hardware and software configurations HCD added meta-data to IOCP and MVSCP information. Therefore, maintaining IODF and MVSCP decks is not sufficient. But HCD allows to export and import HCD definitions. The data is then written in HCDs I/O configuration format, a format similar to IOCP decks or MVSCP decks. It's also a text format and allows to define hardware and software configuration with all the information needed in HCD and the format is fully documented in the HCD books. These HCD configuration definitions are code, and you can automatically build or update an IODF with it. Because it's text, the configuration can be maintained in a source code management system like git. Processing this code is best be done if the configuration data is stored in a MVS data set. Not many source code management systems can work with a dataset. But via scripting, it's easy to extract the configuration data from a file system and copy or transfer it into a dataset and vice versa.
Compared to modern configuration programs and environments, HCD does not provide a remote REST API for importing I/O definitions and managing IODFs. Nevertheless, HCD can be invoked via a Batch interface. Batch programs can be defined and executed via automatic procedures, for example via FTP from a workstation. This way, all IODF processing can be fully automated. Based on this, all pre-requisites to manage I/O configuration as code already exists.
While the interfaces might not yet conform to standards, for example being available via Ansible, it already allows for fully automated management. I/O configuration and HCD are only a small area of configuration for a z/OS system. Many other components are in a similar situation like HCD, hence they can be configured using text files in a dataset in a component specific language. For some parts, creating standard Ansible modules for z/OS has already started. Therefor, running IaC for z/OS and IBM Z can already be done. Nevertheless, that are only the mechanics to run IaC. It still requires, that someone creates and maintains the source. For I/O configurations a good editor for the data is the HCD ISPF application. Other components might need to maintain the source file using any editor.
Some people expect simplification when using IaC. Nevertheless, IaC does not simplify the I/O configuration itself. You still need to understand the language, and what you want to configure. A complex environment still remains a complex environment, even if managed automatically. Nevertheless, when going this route, you may see many areas where you can standardize your configurations and over time get to configuration that is simpler.
------------------------------
Michael Groetzner
z/OS I/O Configuration Architect
------------------------------