Remote installation, customization and deployment of mainframe components

A method comprises packaging a plurality of mainframe software artifacts into a container image, wherein the plurality of mainframe software artifacts are created via installation of software on a first mainframe system using a mainframe installer configured for a first operating system. The method further comprises running a container, based on the container image, on a container distribution platform that uses a host operating system different from the first operating system; and executing one or more scripts within the container. The one or more scripts are configured to install and configure the packaged plurality of mainframe software artifacts onto a second mainframe system communicatively coupled to the container distribution platform, the second mainframe system running the first operating system.

BACKGROUND

Mainframes are centralized computer systems, deployed in a cluster configuration, that can serve many (e.g. thousands) of users. Mainframes can be used in data centers as transaction servers, database servers, e-mail servers and Web servers, etc. In some modern mainframes, the installation, customization, and deployment of mainframe components or software is accomplished in a more manual process than is customary on a personal computer. For example, on a mainframe running a mainframe operating system, such as the z/OS® operating system (Z/OS is a registered trademark of International Business Machines Corporation, Armonk, N.Y.), a typical installation is performed by dedicated installation professionals, usually a unique, dedicated, team, and can take 20 or more manual steps using a mainframe installer, such as System Modification Program/Extended (SMP/E). After the SMP/E installation, the resulting target libraries are typically handed over to a second team of professionals, who then customize the software to be run as a started task or job on the mainframe system. This customization process is also typically comprised of several manual steps. Despite the upfront burden of such a typical mainframe installation and customization processes, such processes using a mainframe installer enable some important advantages, such as helping ensure system integrity, managing multiple software versions, applying updates/patches (such as program temporary fix (PTF) system modifications), maintaining audit and security records, among others. Hence, the use of a mainframe installer, such as SMP/E, is still the standard method used to install mainframe software.

SUMMARY

Aspects of the disclosure may include a computer-implemented method, computer program product, and system. One example of the computer-implemented method comprises packaging a plurality of mainframe software artifacts into a container image, wherein the plurality of mainframe software artifacts are created via installation of software on a first mainframe system using a mainframe installer configured for a first operating system. The method further comprises running a container, based on the container image, on a container distribution platform that uses a host operating system different from the first operating system; and executing one or more scripts within the container. The one or more scripts are configured to install and configure the packaged plurality of mainframe software artifacts onto a second mainframe system communicatively coupled to the container distribution platform, the second mainframe system running the first operating system.

DETAILED DESCRIPTION

Despite the benefits of centralized control over mainframe software installation, such as by using System Modification Program/Extended (SMP/E) on a z/Architecture® system running the z/OS® operating system (z/Architecture is a registered trademark of International Business Machines Corporation), there are also disadvantages as alluded to above. For example, the requirement for multiple different users for each customer to coordinate and participate in the installation or modification of software of the respective customer's mainframe can introduce additional costs and delays. These costs and delays can be caused by the number of different individuals that need to participate and the difficulty in coordinating schedules and timing of the different parts of the installation process. Furthermore, after installation using a mainframe installer, additional customization is typically performed by another team to create an operable system in a conventional system. Thus, from a customer perspective, it would be beneficial to be able to install software or apply updates with less manual intervention while still retaining the benefits of typical mainframe installation processes that use a mainframe installer. The embodiments described herein enable remote and automatic installation and/or modification of software on a mainframe system with minimal customer user interaction required during the installation/modification of the software on the customer's mainframe. In addition, the embodiments described herein still enable the benefits (e.g. control and auditability) of using a mainframe installer, such as SMP/E, as described in more detail below. Furthermore, the embodiments described herein enable the automatic customization of the installed software. Thus, the traditionally separate processes of installation and customization which typically involve different teams of professionals are combined into an automatic process through the embodiments described herein. As a result, the embodiments discussed herein provide the control afforded by the mainframe installation/customization processes but make the mechanics simpler without requiring the specialization required of conventional installations.

FIG. 1depicts one embodiment of an example environment100in which the aspects discussed herein can be implemented. Environment100includes a first mainframe system104(also referred to as a source mainframe system or a product distribution mainframe system) and a second mainframe system106(also referred to as a customer mainframe system) each coupled to a container distribution platform102via a network108. The network108can include one or more private or public computing networks. For example, network108may comprise a private network (e.g., a network with a firewall that blocks non-authorized external access) that is associated with the workload. Alternatively, or additionally, network108may comprise a public network, such as the Internet. Thus, network108may form part of a packet-based network, such as a local area network, a wide-area network, and/or a global network such as the Internet. Network108can include one or more servers, networks, or databases, and can use one or more communication protocols to transfer data to and from the source mainframe system104and to/from the customer mainframe system106. Furthermore, although illustrated inFIG. 1as a single entity, in other examples network108may comprise a plurality of networks, such as a combination of public and/or private networks. The network108can include a variety of types of physical communication channels or “links.” The links can be wired, wireless, optical, and/or any other suitable media. In addition, the network108can include a variety of network hardware and software for performing routing, switching, and other functions, such as routers, switches, base stations, bridges or any other equipment that may be useful to facilitate communicating data. Furthermore, it is to be understood that different systems in the environment100can utilize different networks. For example, in some embodiments, mainframe system104can be communicatively coupled to the container distribution platform102via a local area network or private wide area network whereas mainframe system106is communicatively coupled to the container distribution platform102via a public network, such as the internet.

The source mainframe system104represents a mainframe system of a developer of software to be installed on the customer mainframe system106. Hence, the customer mainframe system106is depicted to represent a customer mainframe system that will receive and apply new or updated software provided by the developer via the container distribution platform102. It is to be understood that although only one customer mainframe system106is depicted inFIG. 1for purposes of illustration, the mainframe software can be installed and configured on more than one customer mainframe system106. The developer can use a mainframe installer to install or update software on the mainframe system104using conventional techniques. For example, a developer can use SMP/E to install or modify software on the mainframe system104running z/OS® operating system. It is to be understood that although SMP/E and z/OS are discussed herein for purposes of explanation, other operating systems and mainframe installers can be used in other embodiments. The installation can be incorporated into part of the build process for the software. As part of the installation performed on the mainframe system104, software artifacts120are generated. The software artifacts120, as used herein, includes the binaries and all information needed to install and run the software on the customer mainframe system106.

The artifacts120are packaged along with one or more scripts122into a container image116that resides on a separate device130in this example. The device130, in this example, is a non-mainframe computer system. However, in other embodiments, the container image116can reside in a z/CX container or a z/Linux system. Thus, in this example, the source mainframe system104is communicatively coupled to the container distribution platform102via the device130. As used herein, a container image is a stand-alone, executable package of a piece of software that includes everything needed to run it: code, runtime, system tools, system libraries, and settings. The one or more scripts122can be run to install the artifacts120on the mainframe system106, as described in more detail herein. The artifacts120and scripts122can be packaged using any suitable containerization technology. For example, in some embodiments, the artifacts120and scripts122are packaged into a Docker® container image (Docker is a registered trademark of Docker, Inc. in the United States and/or other countries). However, it is to be understood that other containerization technologies can be used in other embodiments. For example, such technologies can include but are not limited to LXC Linux containers, Rancher, and VirtualBox.

The container image116is provided or downloaded onto the container distribution platform102via the network108. Container distribution platform102includes a hardware infrastructure110executing a host operating system112above which a container engine114executes. Infrastructure110comprises computing resources including computing devices (e.g., servers, processing units), storage systems (e.g., hard disk drives), and networking resources (e.g., network adapters). An example of infrastructure used to implement one embodiment of a container distribution platform is depicted inFIG. 3.

Host operating system112executes on infrastructure110. In this embodiment, the Host operating system112is the Red Hat® Enterprise Linux® (RHEL) operating system (offered by Red Hat, Inc., Raleigh, N.C., of which RED HAT and ENTERPRISE LINUX are registered trademarks). However, it is to be understood that other operating systems can be used in other embodiments. Notably, the host operating system112is different from the mainframe operating system run by first mainframe system104and second mainframe system106. The container engine114creates, manages, and runs the container118based on the container image116. That is, the container118can be viewed as an instantiation of the container image116. Thus, the container118includes the artifacts120and scripts122from container image116. As discussed above, the artifacts120includes the binaries and libraries from the SMP/E installation performed on the first mainframe system104. As stated above, any suitable containerization technology, such as, Docker, LXC Linux containers, etc. can be used to implement the container engine114. It is to be understood that the implementation details of running the container118and executing the scripts122may vary based on the specific embodiment and technology used.

The scripts122enable the container118to interact with the customer mainframe system106to automatically install and configure the software artifacts120on mainframe system106. In particular, as described in more detail below with respect toFIG. 2, the one or more scripts122establish a connection with the second mainframe system106to upload the artifacts120to the second mainframe system106, create the target libraries, and unpack the binaries in a manner that replicates an SMP/E installation such that the software can be run by the second mainframe system106as a result of the actions performed by the one or more scripts122. Thus, the one or more scripts122are configured to do more than simply upload the software artifacts to the second mainframe106. Rather, the installation performed by the one or more scripts122in container118is based on the container image116which is created as part of an SMP/E install on the first mainframe system104. Thus, the benefits of an SMP/E install are retained, but little to no interaction from the customer or user of the second mainframe system106is required to install the software on the second mainframe system106. Additionally, the one or more scripts122are configured to execute post-installation customization procedures, traditionally performed by a second set of mainframe professionals, that enable the installed software to be run as a mainframe job or service on the second mainframe system106. Furthermore, it is to be understood that the container118can be used to install and/or update software on more than mainframe system even though only one second mainframe system106is depicted inFIG. 1, for ease of illustration. Thus, there is a 1:n relationship between the source or product distribution mainframe system and a plurality of customer mainframe systems such that the software artifacts can be installed and customized on hundreds or even thousands of customer mainframe systems using the software artifacts from the single product distribution mainframe system.

FIG. 2is a flow chart depicting one embodiment of an example method200. Method200can be used for enabling the remote installation, customization and deployment of software components. For example, method200can enable the remote installation, customization, and deployment of SMP/E managed z/OS components from a cloud computing environment. At least part of method200can be implemented by a container distribution platform such as container distribution platform102discussed above.

At block202, a plurality of mainframe software artifacts are packaged into a container image, as discussed above. For example, the mainframe software artifacts can be packaged into a Docker image in some embodiments. The plurality of mainframe software artifacts are created via installation of software on a first mainframe system using a mainframe installer, such as but not limited to SMP/E, configured for a first operating system, such as but not limited to z/OS. The container image can be provided to the container distribution platform from the first mainframe system (or an intermediate device communicatively coupled to both the container distribution platform and the first mainframe system). The container image further includes one or more scripts for installing the packaged plurality of mainframe software artifacts on one or more other mainframe systems, as discussed herein.

At block204, a container, based on the container image, is run on the container distribution platform. As discussed herein, the container distribution platform utilizes a host operating system, such as but not limited to the RHEL operating system, that is different from the first operating system. In some embodiments, the container distribution platform can be implemented in a cloud environment, as discussed herein. In other embodiments, the container distribution platform is not implemented in a cloud environment. For example, in some such embodiments, the container distribution platform can be implemented as a Linux virtual machine coupled to a second mainframe system via a local area network or a wide area network.

At block206, the one or more scripts are executed within the container to install and configure the packaged plurality of mainframe software artifacts on to the second mainframe system communicatively coupled to the container distribution platform. In particular, the scripts enable the automated install of the plurality of mainframe software artifacts with minimal to no human user interaction required. Additionally, the second mainframe system is running the first operating system that is the same as the first operating system of the first mainframe system, as discussed herein.

In some embodiments, the plurality of software artifacts installed on the second mainframe system include a log reader agent that is configured to read a set of change logs at the second mainframe system and send the change logs to a target system, such as via a TCP/IP connection, during a replication process. In some embodiments, the log reader agent is configured to send the change logs to the target system by sending the change logs to a data capture service running on a cloud node which collects the data and communicates the collected change logs to the target system. One such example of a distributed replication system is described in more detail in co-pending U.S. application Ser. No. 16/830,766, which is incorporated herein by reference.

The one or more automated scripts that are executed in the container to install the plurality of mainframe software artifacts are configured to transfer files from the container to the second mainframe system during the install process. For example, the files can be transferred using a secure file transfer protocol (SFTP) to a staging directory (e.g. a Unix System Services (US S) directory). After transferring the files, the one or more automated scripts are configured to perform additional procedures and configuration in order to enable the installed software to run on the second mainframe system. Such procedures performed by the one or more automated scripts can include, but are not limited to, customizing the job control language (JCL), performing authorized program facility (APF) authorization for the installation, and/or otherwise setting up the installed software. For example, in some embodiments involving a log reader agent discussed above, the one or more automated scripts can utilize Secure Shell (SSH) scripts to configured and start the log reader agent. In some embodiments, if the one or more scripts do not have sufficient authorization to APF authorize the libraries or if the one or more automated scripts are not configured to perform the APF authorization, the script authorizing the libraries can be separately executed by an authorized user at a later time. Additionally, in other embodiments, the automated scripts can APF authorize the log reader program load libraries such that they have the authority to pull data. In some such embodiments, if the one or more scripts are not authorized to perform the APF authorization or one of the other procedures, the one or more scripts are configured to obtain temporary authorization from a user having sufficient authority.

For example, executing the one or more scripts to install the plurality of mainframe software artifacts can include, in some embodiments, invoking one or more utilities that output a prompt to a user of the second mainframe having sufficient access rights (such as an administrator of the second mainframe) to request that the user input credentials authorizing modifications to the second mainframe system to install the plurality of software artifacts. This prompt can be output each time authorization is required. In particular, in some embodiments, the one or more scripts that are run within the container do not store the credentials or otherwise include a persistent data capture of the credentials.

Thus, through the execution of method200, the embodiments described herein enable the installation of mainframe software via an automated process while still enabling customization and other benefits of conventional mainframe installers, such as SMP/E, since the installed software artifacts are created through the use of a mainframe installer and then packaged into a container which executes scripts to install the mainframe software artifacts on a remote second mainframe system.

FIG. 3is a block diagram depicting one embodiment of an example computer system12, which can be implemented as a container distribution platform. In particular, the computer system12can be implemented as a cloud computing node in some embodiments. In other embodiments, the computer system12is not implemented as a cloud computing node, as discussed above. Computer system12is only one example of a computer system and is not intended to suggest any limitation as to the scope of use or functionality of embodiments described herein. Computer system12is capable of being implemented and/or performing any of the functionality set forth herein, such as the functionality discussed above with respect to the method200inFIG. 2and the container distribution platform inFIG. 1.

As shown inFIG. 3, the components of the example computer system/server12include, but are not limited to, one or more processors or processing units16, a system memory28, and a bus18that couples various system components including system memory28to processor16.

In addition, as discussed above, the functionality of the controller can be implemented in a cloud computing environment. However, it is to be understood that although this disclosure includes a detailed description on cloud computing, implementation of the teachings recited herein are not limited to a cloud computing environment. Rather, embodiments of the present invention are capable of being implemented in conjunction with any other type of computing environment now known or later developed.

Characteristics are as follows:

Service Models are as follows:

Deployment Models are as follows: