Ansible is rapidly gaining acceptance to automate and orchestrate various types of activities within our organization, including z/OS. This allows organizations to extend automation and normalize skills for provisioning, deployment, orchestration into a single ecosystem wherever it makes sense. Ansible allows you to leverage existing JCL, REXX assets or use more modern capabilities such as Python scripts or z/OSMF and/or Zowe APIs.

Why Ansible?

Many teams within the organization are responsible for automation, this has been the case for decades. Each technology team may approach automation differently, for example on the mainframe we use automation to speed up system startup (IPL) or shutdown, respond to actionable messages, perform job scheduling, speed up system recovery, to name a few. These automation processes can be disparate or inconsistent since each possess their own tooling, scripting languages and user interfaces. In almost every case, mainframe automation is self-contained and does not extend across the enterprise.

What Ansible brings is a way to stitch together z/OS automation as part of an infrastructure or application pipeline. For example, short list of possible use cases includes

• Provisioning middleware (CICS regions or DB2 objects)
• Automate CICS configuration changes across 1 to many CICS regions using CICS CMCI URI modules.
• Probing an LPAR to collect information (health checks, configuration details, auditing) and push results to internal CMDB tools
• Initiate smoke tests on the mainframe after distributed system patching
• Orchestrating multiple components from 1 to many z/OS LPARs (or across sites) in a controlled and reliable way.
• Creating a git repository to store and retrieve mainframe related elements
• Provide control and automation for building development environments
• Use GIT repository for JCL and other elements

Playbook execution takes place on control node using Ansible Tower or the Ansible CLI. Most mainframe tasks will push small self-contained code to execute on the managed z/OS node.

Note that Ansible is not a replacement for the current mainframe automation tools. Tools such as IBM System Automation, Netview, job schedulers or GDPS. These products have tight integration and fast reaction to events and messages. What Ansible brings is a level of orchestration both within the many mainframe targets being managed and as a bridge between distributed applications and associated backend mainframe systems.

What z/OS functions can we do with Ansible?

The z/OS Core Collection within the Ansible Galaxy provides a number of basic functions to submit or manipulate jobs, datasets or invoke commands to help facilitate automation.

https://galaxy.ansible.com/ibm/ibm_zos_core

In addition, IBM provides a library of additional functions within the Z Open Automation Utilities product.

https://www.ibm.com/support/knowledgecenter/en/SSKFYE_1.0.0/zoautil_overview.html

Both products are no charge.

Next Steps

Continuously improving automation is an objective each of us share in my organization. At this time we are reviewing and installing the various pre-requisites needed to perform a Proof of Concept to extend Ansible automation to the mainframe. As we are still formulating use cases, I would be very interested to hear about ideas you may have for potential use cases or in general, how we can use Ansible to enhance automation involving mainframe.

Ansible is rapidly gaining acceptance to automate and orchestrate various types of activities within our organization, including z/OS. This allows organizations to extend automation and normalize skills for provisioning, deployment, orchestration into a single ecosystem wherever it makes sense. Ansible allows you to leverage existing JCL, REXX assets or use more modern capabilities such as Python scripts or z/OSMF and/or Zowe APIs.

Why Ansible?

Many teams within the organization are responsible for automation, this has been the case for decades. Each technology team may approach automation differently, for example on the mainframe we use automation to speed up system startup (IPL) or shutdown, respond to actionable messages, perform job scheduling, speed up system recovery, to name a few. These automation processes can be disparate or inconsistent since each possess their own tooling, scripting languages and user interfaces. In almost every case, mainframe automation is self-contained and does not extend across the enterprise.

What Ansible brings is a way to stitch together z/OS automation as part of an infrastructure or application pipeline. For example, short list of possible use cases includes

• Provisioning middleware (CICS regions or DB2 objects)
• Automate CICS configuration changes across 1 to many CICS regions using CICS CMCI URI modules.
• Probing an LPAR to collect information (health checks, configuration details, auditing) and push results to internal CMDB tools
• Initiate smoke tests on the mainframe after distributed system patching
• Orchestrating multiple components from 1 to many z/OS LPARs (or across sites) in a controlled and reliable way.
• Creating a git repository to store and retrieve mainframe related elements
• Provide control and automation for building development environments
• Use GIT repository for JCL and other elements

Playbook execution takes place on control node using Ansible Tower or the Ansible CLI. Most mainframe tasks will push small self-contained code to execute on the managed z/OS node.

Note that Ansible is not a replacement for the current mainframe automation tools. Tools such as IBM System Automation, Netview, job schedulers or GDPS. These products have tight integration and fast reaction to events and messages. What Ansible brings is a level of orchestration both within the many mainframe targets being managed and as a bridge between distributed applications and associated backend mainframe systems.

What z/OS functions can we do with Ansible?

The z/OS Core Collection within the Ansible Galaxy provides a number of basic functions to submit or manipulate jobs, datasets or invoke commands to help facilitate automation.

https://galaxy.ansible.com/ibm/ibm_zos_core

In addition, IBM provides a library of additional functions within the Z Open Automation Utilities product.

https://www.ibm.com/support/knowledgecenter/en/SSKFYE_1.0.0/zoautil_overview.html

Both products are no charge.

Next Steps

Continuously improving automation is an objective each of us share in my organization. At this time we are reviewing and installing the various pre-requisites needed to perform a Proof of Concept to extend Ansible automation to the mainframe. As we are still formulating use cases, I would be very interested to hear about ideas you may have for potential use cases or in general, how we can use Ansible to enhance automation involving mainframe.

Ansible is rapidly gaining acceptance to automate and orchestrate various types of activities within our organization, including z/OS. This allows organizations to extend automation and normalize skills for provisioning, deployment, orchestration into a single ecosystem wherever it makes sense. Ansible allows you to leverage existing JCL, REXX assets or use more modern capabilities such as Python scripts or z/OSMF and/or Zowe APIs.

Why Ansible?

Many teams within the organization are responsible for automation, this has been the case for decades. Each technology team may approach automation differently, for example on the mainframe we use automation to speed up system startup (IPL) or shutdown, respond to actionable messages, perform job scheduling, speed up system recovery, to name a few. These automation processes can be disparate or inconsistent since each possess their own tooling, scripting languages and user interfaces. In almost every case, mainframe automation is self-contained and does not extend across the enterprise.

What Ansible brings is a way to stitch together z/OS automation as part of an infrastructure or application pipeline. For example, short list of possible use cases includes

• Provisioning middleware (CICS regions or DB2 objects)
• Automate CICS configuration changes across 1 to many CICS regions using CICS CMCI URI modules.
• Probing an LPAR to collect information (health checks, configuration details, auditing) and push results to internal CMDB tools
• Initiate smoke tests on the mainframe after distributed system patching
• Orchestrating multiple components from 1 to many z/OS LPARs (or across sites) in a controlled and reliable way.
• Creating a git repository to store and retrieve mainframe related elements
• Provide control and automation for building development environments
• Use GIT repository for JCL and other elements

Playbook execution takes place on control node using Ansible Tower or the Ansible CLI. Most mainframe tasks will push small self-contained code to execute on the managed z/OS node.

Note that Ansible is not a replacement for the current mainframe automation tools. Tools such as IBM System Automation, Netview, job schedulers or GDPS. These products have tight integration and fast reaction to events and messages. What Ansible brings is a level of orchestration both within the many mainframe targets being managed and as a bridge between distributed applications and associated backend mainframe systems.

What z/OS functions can we do with Ansible?

The z/OS Core Collection within the Ansible Galaxy provides a number of basic functions to submit or manipulate jobs, datasets or invoke commands to help facilitate automation.

https://galaxy.ansible.com/ibm/ibm_zos_core

In addition, IBM provides a library of additional functions within the Z Open Automation Utilities product.

https://www.ibm.com/support/knowledgecenter/en/SSKFYE_1.0.0/zoautil_overview.html

Both products are no charge.

Next Steps

Continuously improving automation is an objective each of us share in my organization. At this time we are reviewing and installing the various pre-requisites needed to perform a Proof of Concept to extend Ansible automation to the mainframe. As we are still formulating use cases, I would be very interested to hear about ideas you may have for potential use cases or in general, how we can use Ansible to enhance automation involving mainframe.

Ansible is rapidly gaining acceptance to automate and orchestrate various types of activities within our organization, including z/OS. This allows organizations to extend automation and normalize skills for provisioning, deployment, orchestration into a single ecosystem wherever it makes sense. Ansible allows you to leverage existing JCL, REXX assets or use more modern capabilities such as Python scripts or z/OSMF and/or Zowe APIs.

Why Ansible?

Many teams within the organization are responsible for automation, this has been the case for decades. Each technology team may approach automation differently, for example on the mainframe we use automation to speed up system startup (IPL) or shutdown, respond to actionable messages, perform job scheduling, speed up system recovery, to name a few. These automation processes can be disparate or inconsistent since each possess their own tooling, scripting languages and user interfaces. In almost every case, mainframe automation is self-contained and does not extend across the enterprise.

What Ansible brings is a way to stitch together z/OS automation as part of an infrastructure or application pipeline. For example, short list of possible use cases includes

• Provisioning middleware (CICS regions or DB2 objects)
• Automate CICS configuration changes across 1 to many CICS regions using CICS CMCI URI modules.
• Probing an LPAR to collect information (health checks, configuration details, auditing) and push results to internal CMDB tools
• Initiate smoke tests on the mainframe after distributed system patching
• Orchestrating multiple components from 1 to many z/OS LPARs (or across sites) in a controlled and reliable way.
• Creating a git repository to store and retrieve mainframe related elements
• Provide control and automation for building development environments
• Use GIT repository for JCL and other elements

Playbook execution takes place on control node using Ansible Tower or the Ansible CLI. Most mainframe tasks will push small self-contained code to execute on the managed z/OS node.

Note that Ansible is not a replacement for the current mainframe automation tools. Tools such as IBM System Automation, Netview, job schedulers or GDPS. These products have tight integration and fast reaction to events and messages. What Ansible brings is a level of orchestration both within the many mainframe targets being managed and as a bridge between distributed applications and associated backend mainframe systems.

What z/OS functions can we do with Ansible?

The z/OS Core Collection within the Ansible Galaxy provides a number of basic functions to submit or manipulate jobs, datasets or invoke commands to help facilitate automation.

https://galaxy.ansible.com/ibm/ibm_zos_core

In addition, IBM provides a library of additional functions within the Z Open Automation Utilities product.

https://www.ibm.com/support/knowledgecenter/en/SSKFYE_1.0.0/zoautil_overview.html

Both products are no charge.

Next Steps

Continuously improving automation is an objective each of us share in my organization. At this time we are reviewing and installing the various pre-requisites needed to perform a Proof of Concept to extend Ansible automation to the mainframe. As we are still formulating use cases, I would be very interested to hear about ideas you may have for potential use cases or in general, how we can use Ansible to enhance automation involving mainframe.

Ansible is rapidly gaining acceptance to automate and orchestrate various types of activities within our organization, including z/OS. This allows organizations to extend automation and normalize skills for provisioning, deployment, orchestration into a single ecosystem wherever it makes sense. Ansible allows you to leverage existing JCL, REXX assets or use more modern capabilities such as Python scripts or z/OSMF and/or Zowe APIs.

Why Ansible?

Many teams within the organization are responsible for automation, this has been the case for decades. Each technology team may approach automation differently, for example on the mainframe we use automation to speed up system startup (IPL) or shutdown, respond to actionable messages, perform job scheduling, speed up system recovery, to name a few. These automation processes can be disparate or inconsistent since each possess their own tooling, scripting languages and user interfaces. In almost every case, mainframe automation is self-contained and does not extend across the enterprise.

What Ansible brings is a way to stitch together z/OS automation as part of an infrastructure or application pipeline. For example, short list of possible use cases includes

• Provisioning middleware (CICS regions or DB2 objects)
• Automate CICS configuration changes across 1 to many CICS regions using CICS CMCI URI modules.
• Probing an LPAR to collect information (health checks, configuration details, auditing) and push results to internal CMDB tools
• Initiate smoke tests on the mainframe after distributed system patching
• Orchestrating multiple components from 1 to many z/OS LPARs (or across sites) in a controlled and reliable way.
• Creating a git repository to store and retrieve mainframe related elements
• Provide control and automation for building development environments
• Use GIT repository for JCL and other elements

Playbook execution takes place on control node using Ansible Tower or the Ansible CLI. Most mainframe tasks will push small self-contained code to execute on the managed z/OS node.

Note that Ansible is not a replacement for the current mainframe automation tools. Tools such as IBM System Automation, Netview, job schedulers or GDPS. These products have tight integration and fast reaction to events and messages. What Ansible brings is a level of orchestration both within the many mainframe targets being managed and as a bridge between distributed applications and associated backend mainframe systems.

What z/OS functions can we do with Ansible?

The z/OS Core Collection within the Ansible Galaxy provides a number of basic functions to submit or manipulate jobs, datasets or invoke commands to help facilitate automation.

https://galaxy.ansible.com/ibm/ibm_zos_core

In addition, IBM provides a library of additional functions within the Z Open Automation Utilities product.

https://www.ibm.com/support/knowledgecenter/en/SSKFYE_1.0.0/zoautil_overview.html

Both products are no charge.

Next Steps

Continuously improving automation is an objective each of us share in my organization. At this time we are reviewing and installing the various pre-requisites needed to perform a Proof of Concept to extend Ansible automation to the mainframe. As we are still formulating use cases, I would be very interested to hear about ideas you may have for potential use cases or in general, how we can use Ansible to enhance automation involving mainframe.

Ansible is rapidly gaining acceptance to automate and orchestrate various types of activities within our organization, including z/OS. This allows organizations to extend automation and normalize skills for provisioning, deployment, orchestration into a single ecosystem wherever it makes sense. Ansible allows you to leverage existing JCL, REXX assets or use more modern capabilities such as Python scripts or z/OSMF and/or Zowe APIs.

Why Ansible?

Many teams within the organization are responsible for automation, this has been the case for decades. Each technology team may approach automation differently, for example on the mainframe we use automation to speed up system startup (IPL) or shutdown, respond to actionable messages, perform job scheduling, speed up system recovery, to name a few. These automation processes can be disparate or inconsistent since each possess their own tooling, scripting languages and user interfaces. In almost every case, mainframe automation is self-contained and does not extend across the enterprise.

What Ansible brings is a way to stitch together z/OS automation as part of an infrastructure or application pipeline. For example, short list of possible use cases includes

• Provisioning middleware (CICS regions or DB2 objects)
• Automate CICS configuration changes across 1 to many CICS regions using CICS CMCI URI modules.
• Probing an LPAR to collect information (health checks, configuration details, auditing) and push results to internal CMDB tools
• Initiate smoke tests on the mainframe after distributed system patching
• Orchestrating multiple components from 1 to many z/OS LPARs (or across sites) in a controlled and reliable way.
• Creating a git repository to store and retrieve mainframe related elements
• Provide control and automation for building development environments
• Use GIT repository for JCL and other elements

Playbook execution takes place on control node using Ansible Tower or the Ansible CLI. Most mainframe tasks will push small self-contained code to execute on the managed z/OS node.

Note that Ansible is not a replacement for the current mainframe automation tools. Tools such as IBM System Automation, Netview, job schedulers or GDPS. These products have tight integration and fast reaction to events and messages. What Ansible brings is a level of orchestration both within the many mainframe targets being managed and as a bridge between distributed applications and associated backend mainframe systems.

What z/OS functions can we do with Ansible?

The z/OS Core Collection within the Ansible Galaxy provides a number of basic functions to submit or manipulate jobs, datasets or invoke commands to help facilitate automation.

https://galaxy.ansible.com/ibm/ibm_zos_core

In addition, IBM provides a library of additional functions within the Z Open Automation Utilities product.

https://www.ibm.com/support/knowledgecenter/en/SSKFYE_1.0.0/zoautil_overview.html

Both products are no charge.

Next Steps

Continuously improving automation is an objective each of us share in my organization. At this time we are reviewing and installing the various pre-requisites needed to perform a Proof of Concept to extend Ansible automation to the mainframe. As we are still formulating use cases, I would be very interested to hear about ideas you may have for potential use cases or in general, how we can use Ansible to enhance automation involving mainframe.

Ansible is rapidly gaining acceptance to automate and orchestrate various types of activities within our organization, including z/OS. This allows organizations to extend automation and normalize skills for provisioning, deployment, orchestration into a single ecosystem wherever it makes sense. Ansible allows you to leverage existing JCL, REXX assets or use more modern capabilities such as Python scripts or z/OSMF and/or Zowe APIs.

Why Ansible?

Many teams within the organization are responsible for automation, this has been the case for decades. Each technology team may approach automation differently, for example on the mainframe we use automation to speed up system startup (IPL) or shutdown, respond to actionable messages, perform job scheduling, speed up system recovery, to name a few. These automation processes can be disparate or inconsistent since each possess their own tooling, scripting languages and user interfaces. In almost every case, mainframe automation is self-contained and does not extend across the enterprise.

What Ansible brings is a way to stitch together z/OS automation as part of an infrastructure or application pipeline. For example, short list of possible use cases includes

• Provisioning middleware (CICS regions or DB2 objects)
• Automate CICS configuration changes across 1 to many CICS regions using CICS CMCI URI modules.
• Probing an LPAR to collect information (health checks, configuration details, auditing) and push results to internal CMDB tools
• Initiate smoke tests on the mainframe after distributed system patching
• Orchestrating multiple components from 1 to many z/OS LPARs (or across sites) in a controlled and reliable way.
• Creating a git repository to store and retrieve mainframe related elements
• Provide control and automation for building development environments
• Use GIT repository for JCL and other elements

Playbook execution takes place on control node using Ansible Tower or the Ansible CLI. Most mainframe tasks will push small self-contained code to execute on the managed z/OS node.

Note that Ansible is not a replacement for the current mainframe automation tools. Tools such as IBM System Automation, Netview, job schedulers or GDPS. These products have tight integration and fast reaction to events and messages. What Ansible brings is a level of orchestration both within the many mainframe targets being managed and as a bridge between distributed applications and associated backend mainframe systems.

What z/OS functions can we do with Ansible?

The z/OS Core Collection within the Ansible Galaxy provides a number of basic functions to submit or manipulate jobs, datasets or invoke commands to help facilitate automation.

https://galaxy.ansible.com/ibm/ibm_zos_core

In addition, IBM provides a library of additional functions within the Z Open Automation Utilities product.

https://www.ibm.com/support/knowledgecenter/en/SSKFYE_1.0.0/zoautil_overview.html

Both products are no charge.

Next Steps

Continuously improving automation is an objective each of us share in my organization. At this time we are reviewing and installing the various pre-requisites needed to perform a Proof of Concept to extend Ansible automation to the mainframe. As we are still formulating use cases, I would be very interested to hear about ideas you may have for potential use cases or in general, how we can use Ansible to enhance automation involving mainframe.

Ansible is rapidly gaining acceptance to automate and orchestrate various types of activities within our organization, including z/OS. This allows organizations to extend automation and normalize skills for provisioning, deployment, orchestration into a single ecosystem wherever it makes sense. Ansible allows you to leverage existing JCL, REXX assets or use more modern capabilities such as Python scripts or z/OSMF and/or Zowe APIs.

Why Ansible?

Many teams within the organization are responsible for automation, this has been the case for decades. Each technology team may approach automation differently, for example on the mainframe we use automation to speed up system startup (IPL) or shutdown, respond to actionable messages, perform job scheduling, speed up system recovery, to name a few. These automation processes can be disparate or inconsistent since each possess their own tooling, scripting languages and user interfaces. In almost every case, mainframe automation is self-contained and does not extend across the enterprise.

What Ansible brings is a way to stitch together z/OS automation as part of an infrastructure or application pipeline. For example, short list of possible use cases includes

• Provisioning middleware (CICS regions or DB2 objects)
• Automate CICS configuration changes across 1 to many CICS regions using CICS CMCI URI modules.
• Probing an LPAR to collect information (health checks, configuration details, auditing) and push results to internal CMDB tools
• Initiate smoke tests on the mainframe after distributed system patching
• Orchestrating multiple components from 1 to many z/OS LPARs (or across sites) in a controlled and reliable way.
• Creating a git repository to store and retrieve mainframe related elements
• Provide control and automation for building development environments
• Use GIT repository for JCL and other elements

Playbook execution takes place on control node using Ansible Tower or the Ansible CLI. Most mainframe tasks will push small self-contained code to execute on the managed z/OS node.

Note that Ansible is not a replacement for the current mainframe automation tools. Tools such as IBM System Automation, Netview, job schedulers or GDPS. These products have tight integration and fast reaction to events and messages. What Ansible brings is a level of orchestration both within the many mainframe targets being managed and as a bridge between distributed applications and associated backend mainframe systems.

What z/OS functions can we do with Ansible?

The z/OS Core Collection within the Ansible Galaxy provides a number of basic functions to submit or manipulate jobs, datasets or invoke commands to help facilitate automation.

https://galaxy.ansible.com/ibm/ibm_zos_core

In addition, IBM provides a library of additional functions within the Z Open Automation Utilities product.

https://www.ibm.com/support/knowledgecenter/en/SSKFYE_1.0.0/zoautil_overview.html

Both products are no charge.

Next Steps

Continuously improving automation is an objective each of us share in my organization. At this time we are reviewing and installing the various pre-requisites needed to perform a Proof of Concept to extend Ansible automation to the mainframe. As we are still formulating use cases, I would be very interested to hear about ideas you may have for potential use cases or in general, how we can use Ansible to enhance automation involving mainframe.

There are 4 products (PIDs) that ZOAU (HAL5100) is available in:

• IBM Z Open Development (Program ID: 5737-I22)
• IBM Application Delivery Foundation for z Systems (Program ID: 5655-AC5)
• IBM Dependency Based Build (Program ID: 5737-K80)
• IBM Z Open Automation Utilities (Program ID: 5698-PA1 for the base product and Program ID: 5698-PAS for service/support)

Ansible is rapidly gaining acceptance to automate and orchestrate various types of activities within our organization, including z/OS. This allows organizations to extend automation and normalize skills for provisioning, deployment, orchestration into a single ecosystem wherever it makes sense. Ansible allows you to leverage existing JCL, REXX assets or use more modern capabilities such as Python scripts or z/OSMF and/or Zowe APIs.

Why Ansible?

Many teams within the organization are responsible for automation, this has been the case for decades. Each technology team may approach automation differently, for example on the mainframe we use automation to speed up system startup (IPL) or shutdown, respond to actionable messages, perform job scheduling, speed up system recovery, to name a few. These automation processes can be disparate or inconsistent since each possess their own tooling, scripting languages and user interfaces. In almost every case, mainframe automation is self-contained and does not extend across the enterprise.

What Ansible brings is a way to stitch together z/OS automation as part of an infrastructure or application pipeline. For example, short list of possible use cases includes

• Provisioning middleware (CICS regions or DB2 objects)
• Automate CICS configuration changes across 1 to many CICS regions using CICS CMCI URI modules.
• Probing an LPAR to collect information (health checks, configuration details, auditing) and push results to internal CMDB tools
• Initiate smoke tests on the mainframe after distributed system patching
• Orchestrating multiple components from 1 to many z/OS LPARs (or across sites) in a controlled and reliable way.
• Creating a git repository to store and retrieve mainframe related elements
• Provide control and automation for building development environments
• Use GIT repository for JCL and other elements

Playbook execution takes place on control node using Ansible Tower or the Ansible CLI. Most mainframe tasks will push small self-contained code to execute on the managed z/OS node.

Note that Ansible is not a replacement for the current mainframe automation tools. Tools such as IBM System Automation, Netview, job schedulers or GDPS. These products have tight integration and fast reaction to events and messages. What Ansible brings is a level of orchestration both within the many mainframe targets being managed and as a bridge between distributed applications and associated backend mainframe systems.

What z/OS functions can we do with Ansible?

The z/OS Core Collection within the Ansible Galaxy provides a number of basic functions to submit or manipulate jobs, datasets or invoke commands to help facilitate automation.

https://galaxy.ansible.com/ibm/ibm_zos_core

In addition, IBM provides a library of additional functions within the Z Open Automation Utilities product.

https://www.ibm.com/support/knowledgecenter/en/SSKFYE_1.0.0/zoautil_overview.html

Both products are no charge.

Next Steps

Continuously improving automation is an objective each of us share in my organization. At this time we are reviewing and installing the various pre-requisites needed to perform a Proof of Concept to extend Ansible automation to the mainframe. As we are still formulating use cases, I would be very interested to hear about ideas you may have for potential use cases or in general, how we can use Ansible to enhance automation involving mainframe.

There are 4 products (PIDs) that ZOAU (HAL5100) is available in:

• IBM Z Open Development (Program ID: 5737-I22)
• IBM Application Delivery Foundation for z Systems (Program ID: 5655-AC5)
• IBM Dependency Based Build (Program ID: 5737-K80)
• IBM Z Open Automation Utilities (Program ID: 5698-PA1 for the base product and Program ID: 5698-PAS for service/support)

Ansible is rapidly gaining acceptance to automate and orchestrate various types of activities within our organization, including z/OS. This allows organizations to extend automation and normalize skills for provisioning, deployment, orchestration into a single ecosystem wherever it makes sense. Ansible allows you to leverage existing JCL, REXX assets or use more modern capabilities such as Python scripts or z/OSMF and/or Zowe APIs.

Why Ansible?

Many teams within the organization are responsible for automation, this has been the case for decades. Each technology team may approach automation differently, for example on the mainframe we use automation to speed up system startup (IPL) or shutdown, respond to actionable messages, perform job scheduling, speed up system recovery, to name a few. These automation processes can be disparate or inconsistent since each possess their own tooling, scripting languages and user interfaces. In almost every case, mainframe automation is self-contained and does not extend across the enterprise.

What Ansible brings is a way to stitch together z/OS automation as part of an infrastructure or application pipeline. For example, short list of possible use cases includes

• Provisioning middleware (CICS regions or DB2 objects)
• Automate CICS configuration changes across 1 to many CICS regions using CICS CMCI URI modules.
• Probing an LPAR to collect information (health checks, configuration details, auditing) and push results to internal CMDB tools
• Initiate smoke tests on the mainframe after distributed system patching
• Orchestrating multiple components from 1 to many z/OS LPARs (or across sites) in a controlled and reliable way.
• Creating a git repository to store and retrieve mainframe related elements
• Provide control and automation for building development environments
• Use GIT repository for JCL and other elements

Playbook execution takes place on control node using Ansible Tower or the Ansible CLI. Most mainframe tasks will push small self-contained code to execute on the managed z/OS node.

Note that Ansible is not a replacement for the current mainframe automation tools. Tools such as IBM System Automation, Netview, job schedulers or GDPS. These products have tight integration and fast reaction to events and messages. What Ansible brings is a level of orchestration both within the many mainframe targets being managed and as a bridge between distributed applications and associated backend mainframe systems.

What z/OS functions can we do with Ansible?

The z/OS Core Collection within the Ansible Galaxy provides a number of basic functions to submit or manipulate jobs, datasets or invoke commands to help facilitate automation.

https://galaxy.ansible.com/ibm/ibm_zos_core

In addition, IBM provides a library of additional functions within the Z Open Automation Utilities product.

https://www.ibm.com/support/knowledgecenter/en/SSKFYE_1.0.0/zoautil_overview.html

Both products are no charge.

Next Steps

Continuously improving automation is an objective each of us share in my organization. At this time we are reviewing and installing the various pre-requisites needed to perform a Proof of Concept to extend Ansible automation to the mainframe. As we are still formulating use cases, I would be very interested to hear about ideas you may have for potential use cases or in general, how we can use Ansible to enhance automation involving mainframe.

There are 4 products (PIDs) that ZOAU (HAL5100) is available in:

• IBM Z Open Development (Program ID: 5737-I22)
• IBM Application Delivery Foundation for z Systems (Program ID: 5655-AC5)
• IBM Dependency Based Build (Program ID: 5737-K80)
• IBM Z Open Automation Utilities (Program ID: 5698-PA1 for the base product and Program ID: 5698-PAS for service/support)

Ansible is rapidly gaining acceptance to automate and orchestrate various types of activities within our organization, including z/OS. This allows organizations to extend automation and normalize skills for provisioning, deployment, orchestration into a single ecosystem wherever it makes sense. Ansible allows you to leverage existing JCL, REXX assets or use more modern capabilities such as Python scripts or z/OSMF and/or Zowe APIs.

Why Ansible?

Many teams within the organization are responsible for automation, this has been the case for decades. Each technology team may approach automation differently, for example on the mainframe we use automation to speed up system startup (IPL) or shutdown, respond to actionable messages, perform job scheduling, speed up system recovery, to name a few. These automation processes can be disparate or inconsistent since each possess their own tooling, scripting languages and user interfaces. In almost every case, mainframe automation is self-contained and does not extend across the enterprise.

What Ansible brings is a way to stitch together z/OS automation as part of an infrastructure or application pipeline. For example, short list of possible use cases includes

• Provisioning middleware (CICS regions or DB2 objects)
• Automate CICS configuration changes across 1 to many CICS regions using CICS CMCI URI modules.
• Probing an LPAR to collect information (health checks, configuration details, auditing) and push results to internal CMDB tools
• Initiate smoke tests on the mainframe after distributed system patching
• Orchestrating multiple components from 1 to many z/OS LPARs (or across sites) in a controlled and reliable way.
• Creating a git repository to store and retrieve mainframe related elements
• Provide control and automation for building development environments
• Use GIT repository for JCL and other elements

Playbook execution takes place on control node using Ansible Tower or the Ansible CLI. Most mainframe tasks will push small self-contained code to execute on the managed z/OS node.

Note that Ansible is not a replacement for the current mainframe automation tools. Tools such as IBM System Automation, Netview, job schedulers or GDPS. These products have tight integration and fast reaction to events and messages. What Ansible brings is a level of orchestration both within the many mainframe targets being managed and as a bridge between distributed applications and associated backend mainframe systems.

What z/OS functions can we do with Ansible?

The z/OS Core Collection within the Ansible Galaxy provides a number of basic functions to submit or manipulate jobs, datasets or invoke commands to help facilitate automation.

https://galaxy.ansible.com/ibm/ibm_zos_core

In addition, IBM provides a library of additional functions within the Z Open Automation Utilities product.

https://www.ibm.com/support/knowledgecenter/en/SSKFYE_1.0.0/zoautil_overview.html

Both products are no charge.

Next Steps

Continuously improving automation is an objective each of us share in my organization. At this time we are reviewing and installing the various pre-requisites needed to perform a Proof of Concept to extend Ansible automation to the mainframe. As we are still formulating use cases, I would be very interested to hear about ideas you may have for potential use cases or in general, how we can use Ansible to enhance automation involving mainframe.

Hey Phillip - Very happy to hear that you find the content solution page helpful! We always welcome feedback on what else would be useful.

On your question about Python, we strongly recommend that clients use the IBM Open Enterprise Python for z/OS. The Rocket Python works today with Ansible and ZOAU, but we recommend that you make plans to move to the IBM Open Enterprise Python for z/OS.

On your suggestion, I think it's good to take a step back when considering both z/OSMF and Ansible. Ansible (the open source version) and the Red Hat Ansible Automation Platform (the supported, enterprise version) are more than a workflow engine, they are tackling the problem of centralizing as much automation throughout the enterprise as possible for:

• normalization of skills across disciplines -  no matter what platform, OS, or network device Ansible allows you to write yaml (roles, playbooks) to both write new automation or invoke existing automation
• orchestration across LPARs, across platforms and devices for complex deployments
• visibility to not only the immediate teams using the automation but other teams that may be able to benefit from automation reuse
• visibility to lines of business on how much automation is being used to help make decisions and see results of their investment

z/OSMF certainly does some of this at the z/OS level but what we are finding with our clients is that many are already taking steps toward an enterprise-wide Ansible strategy and we are meeting them there.

There is also a z/OSMF collection in the works (available on Galaxy) so that Ansible can drive z/OSMF workflows and services beyond just calling the REST APIs. Some clients who have already made an investment in z/OSMF want to interface from Ansible through z/OSMF while others are really embracing the agentless approach via SSH/Python/ZOAU. Both approaches are available, and can be mixed and matched. 

There are 4 products (PIDs) that ZOAU (HAL5100) is available in:

• IBM Z Open Development (Program ID: 5737-I22)
• IBM Application Delivery Foundation for z Systems (Program ID: 5655-AC5)
• IBM Dependency Based Build (Program ID: 5737-K80)
• IBM Z Open Automation Utilities (Program ID: 5698-PA1 for the base product and Program ID: 5698-PAS for service/support)

Ansible is rapidly gaining acceptance to automate and orchestrate various types of activities within our organization, including z/OS. This allows organizations to extend automation and normalize skills for provisioning, deployment, orchestration into a single ecosystem wherever it makes sense. Ansible allows you to leverage existing JCL, REXX assets or use more modern capabilities such as Python scripts or z/OSMF and/or Zowe APIs.

Why Ansible?

Many teams within the organization are responsible for automation, this has been the case for decades. Each technology team may approach automation differently, for example on the mainframe we use automation to speed up system startup (IPL) or shutdown, respond to actionable messages, perform job scheduling, speed up system recovery, to name a few. These automation processes can be disparate or inconsistent since each possess their own tooling, scripting languages and user interfaces. In almost every case, mainframe automation is self-contained and does not extend across the enterprise.

What Ansible brings is a way to stitch together z/OS automation as part of an infrastructure or application pipeline. For example, short list of possible use cases includes

• Provisioning middleware (CICS regions or DB2 objects)
• Automate CICS configuration changes across 1 to many CICS regions using CICS CMCI URI modules.
• Probing an LPAR to collect information (health checks, configuration details, auditing) and push results to internal CMDB tools
• Initiate smoke tests on the mainframe after distributed system patching
• Orchestrating multiple components from 1 to many z/OS LPARs (or across sites) in a controlled and reliable way.
• Creating a git repository to store and retrieve mainframe related elements
• Provide control and automation for building development environments
• Use GIT repository for JCL and other elements

Playbook execution takes place on control node using Ansible Tower or the Ansible CLI. Most mainframe tasks will push small self-contained code to execute on the managed z/OS node.

Note that Ansible is not a replacement for the current mainframe automation tools. Tools such as IBM System Automation, Netview, job schedulers or GDPS. These products have tight integration and fast reaction to events and messages. What Ansible brings is a level of orchestration both within the many mainframe targets being managed and as a bridge between distributed applications and associated backend mainframe systems.

What z/OS functions can we do with Ansible?

The z/OS Core Collection within the Ansible Galaxy provides a number of basic functions to submit or manipulate jobs, datasets or invoke commands to help facilitate automation.

https://galaxy.ansible.com/ibm/ibm_zos_core

In addition, IBM provides a library of additional functions within the Z Open Automation Utilities product.

https://www.ibm.com/support/knowledgecenter/en/SSKFYE_1.0.0/zoautil_overview.html

Both products are no charge.

Next Steps

Continuously improving automation is an objective each of us share in my organization. At this time we are reviewing and installing the various pre-requisites needed to perform a Proof of Concept to extend Ansible automation to the mainframe. As we are still formulating use cases, I would be very interested to hear about ideas you may have for potential use cases or in general, how we can use Ansible to enhance automation involving mainframe.

Hey Phillip - Very happy to hear that you find the content solution page helpful! We always welcome feedback on what else would be useful.

On your question about Python, we strongly recommend that clients use the IBM Open Enterprise Python for z/OS. The Rocket Python works today with Ansible and ZOAU, but we recommend that you make plans to move to the IBM Open Enterprise Python for z/OS.

On your suggestion, I think it's good to take a step back when considering both z/OSMF and Ansible. Ansible (the open source version) and the Red Hat Ansible Automation Platform (the supported, enterprise version) are more than a workflow engine, they are tackling the problem of centralizing as much automation throughout the enterprise as possible for:

• normalization of skills across disciplines -  no matter what platform, OS, or network device Ansible allows you to write yaml (roles, playbooks) to both write new automation or invoke existing automation
• orchestration across LPARs, across platforms and devices for complex deployments
• visibility to not only the immediate teams using the automation but other teams that may be able to benefit from automation reuse
• visibility to lines of business on how much automation is being used to help make decisions and see results of their investment

z/OSMF certainly does some of this at the z/OS level but what we are finding with our clients is that many are already taking steps toward an enterprise-wide Ansible strategy and we are meeting them there.

There is also a z/OSMF collection in the works (available on Galaxy) so that Ansible can drive z/OSMF workflows and services beyond just calling the REST APIs. Some clients who have already made an investment in z/OSMF want to interface from Ansible through z/OSMF while others are really embracing the agentless approach via SSH/Python/ZOAU. Both approaches are available, and can be mixed and matched. 

There are 4 products (PIDs) that ZOAU (HAL5100) is available in:

• IBM Z Open Development (Program ID: 5737-I22)
• IBM Application Delivery Foundation for z Systems (Program ID: 5655-AC5)
• IBM Dependency Based Build (Program ID: 5737-K80)
• IBM Z Open Automation Utilities (Program ID: 5698-PA1 for the base product and Program ID: 5698-PAS for service/support)

Ansible is rapidly gaining acceptance to automate and orchestrate various types of activities within our organization, including z/OS. This allows organizations to extend automation and normalize skills for provisioning, deployment, orchestration into a single ecosystem wherever it makes sense. Ansible allows you to leverage existing JCL, REXX assets or use more modern capabilities such as Python scripts or z/OSMF and/or Zowe APIs.

Why Ansible?

Many teams within the organization are responsible for automation, this has been the case for decades. Each technology team may approach automation differently, for example on the mainframe we use automation to speed up system startup (IPL) or shutdown, respond to actionable messages, perform job scheduling, speed up system recovery, to name a few. These automation processes can be disparate or inconsistent since each possess their own tooling, scripting languages and user interfaces. In almost every case, mainframe automation is self-contained and does not extend across the enterprise.

What Ansible brings is a way to stitch together z/OS automation as part of an infrastructure or application pipeline. For example, short list of possible use cases includes

• Provisioning middleware (CICS regions or DB2 objects)
• Automate CICS configuration changes across 1 to many CICS regions using CICS CMCI URI modules.
• Probing an LPAR to collect information (health checks, configuration details, auditing) and push results to internal CMDB tools
• Initiate smoke tests on the mainframe after distributed system patching
• Orchestrating multiple components from 1 to many z/OS LPARs (or across sites) in a controlled and reliable way.
• Creating a git repository to store and retrieve mainframe related elements
• Provide control and automation for building development environments
• Use GIT repository for JCL and other elements

Playbook execution takes place on control node using Ansible Tower or the Ansible CLI. Most mainframe tasks will push small self-contained code to execute on the managed z/OS node.

Note that Ansible is not a replacement for the current mainframe automation tools. Tools such as IBM System Automation, Netview, job schedulers or GDPS. These products have tight integration and fast reaction to events and messages. What Ansible brings is a level of orchestration both within the many mainframe targets being managed and as a bridge between distributed applications and associated backend mainframe systems.

What z/OS functions can we do with Ansible?

The z/OS Core Collection within the Ansible Galaxy provides a number of basic functions to submit or manipulate jobs, datasets or invoke commands to help facilitate automation.

https://galaxy.ansible.com/ibm/ibm_zos_core

In addition, IBM provides a library of additional functions within the Z Open Automation Utilities product.

https://www.ibm.com/support/knowledgecenter/en/SSKFYE_1.0.0/zoautil_overview.html

Both products are no charge.

Next Steps

Continuously improving automation is an objective each of us share in my organization. At this time we are reviewing and installing the various pre-requisites needed to perform a Proof of Concept to extend Ansible automation to the mainframe. As we are still formulating use cases, I would be very interested to hear about ideas you may have for potential use cases or in general, how we can use Ansible to enhance automation involving mainframe.

Ansible is rapidly gaining acceptance to automate and orchestrate various types of activities within our organization, including z/OS. This allows organizations to extend automation and normalize skills for provisioning, deployment, orchestration into a single ecosystem wherever it makes sense. Ansible allows you to leverage existing JCL, REXX assets or use more modern capabilities such as Python scripts or z/OSMF and/or Zowe APIs.

Why Ansible?

Many teams within the organization are responsible for automation, this has been the case for decades. Each technology team may approach automation differently, for example on the mainframe we use automation to speed up system startup (IPL) or shutdown, respond to actionable messages, perform job scheduling, speed up system recovery, to name a few. These automation processes can be disparate or inconsistent since each possess their own tooling, scripting languages and user interfaces. In almost every case, mainframe automation is self-contained and does not extend across the enterprise.

What Ansible brings is a way to stitch together z/OS automation as part of an infrastructure or application pipeline. For example, short list of possible use cases includes

• Provisioning middleware (CICS regions or DB2 objects)
• Automate CICS configuration changes across 1 to many CICS regions using CICS CMCI URI modules.
• Probing an LPAR to collect information (health checks, configuration details, auditing) and push results to internal CMDB tools
• Initiate smoke tests on the mainframe after distributed system patching
• Orchestrating multiple components from 1 to many z/OS LPARs (or across sites) in a controlled and reliable way.
• Creating a git repository to store and retrieve mainframe related elements
• Provide control and automation for building development environments
• Use GIT repository for JCL and other elements

Playbook execution takes place on control node using Ansible Tower or the Ansible CLI. Most mainframe tasks will push small self-contained code to execute on the managed z/OS node.

Note that Ansible is not a replacement for the current mainframe automation tools. Tools such as IBM System Automation, Netview, job schedulers or GDPS. These products have tight integration and fast reaction to events and messages. What Ansible brings is a level of orchestration both within the many mainframe targets being managed and as a bridge between distributed applications and associated backend mainframe systems.

What z/OS functions can we do with Ansible?

The z/OS Core Collection within the Ansible Galaxy provides a number of basic functions to submit or manipulate jobs, datasets or invoke commands to help facilitate automation.

https://galaxy.ansible.com/ibm/ibm_zos_core

In addition, IBM provides a library of additional functions within the Z Open Automation Utilities product.

https://www.ibm.com/support/knowledgecenter/en/SSKFYE_1.0.0/zoautil_overview.html

Both products are no charge.

Next Steps

Continuously improving automation is an objective each of us share in my organization. At this time we are reviewing and installing the various pre-requisites needed to perform a Proof of Concept to extend Ansible automation to the mainframe. As we are still formulating use cases, I would be very interested to hear about ideas you may have for potential use cases or in general, how we can use Ansible to enhance automation involving mainframe.

Ansible is rapidly gaining acceptance to automate and orchestrate various types of activities within our organization, including z/OS. This allows organizations to extend automation and normalize skills for provisioning, deployment, orchestration into a single ecosystem wherever it makes sense. Ansible allows you to leverage existing JCL, REXX assets or use more modern capabilities such as Python scripts or z/OSMF and/or Zowe APIs.

Why Ansible?

Many teams within the organization are responsible for automation, this has been the case for decades. Each technology team may approach automation differently, for example on the mainframe we use automation to speed up system startup (IPL) or shutdown, respond to actionable messages, perform job scheduling, speed up system recovery, to name a few. These automation processes can be disparate or inconsistent since each possess their own tooling, scripting languages and user interfaces. In almost every case, mainframe automation is self-contained and does not extend across the enterprise.

What Ansible brings is a way to stitch together z/OS automation as part of an infrastructure or application pipeline. For example, short list of possible use cases includes

• Provisioning middleware (CICS regions or DB2 objects)
• Automate CICS configuration changes across 1 to many CICS regions using CICS CMCI URI modules.
• Probing an LPAR to collect information (health checks, configuration details, auditing) and push results to internal CMDB tools
• Initiate smoke tests on the mainframe after distributed system patching
• Orchestrating multiple components from 1 to many z/OS LPARs (or across sites) in a controlled and reliable way.
• Creating a git repository to store and retrieve mainframe related elements
• Provide control and automation for building development environments
• Use GIT repository for JCL and other elements

Playbook execution takes place on control node using Ansible Tower or the Ansible CLI. Most mainframe tasks will push small self-contained code to execute on the managed z/OS node.

Note that Ansible is not a replacement for the current mainframe automation tools. Tools such as IBM System Automation, Netview, job schedulers or GDPS. These products have tight integration and fast reaction to events and messages. What Ansible brings is a level of orchestration both within the many mainframe targets being managed and as a bridge between distributed applications and associated backend mainframe systems.

What z/OS functions can we do with Ansible?

The z/OS Core Collection within the Ansible Galaxy provides a number of basic functions to submit or manipulate jobs, datasets or invoke commands to help facilitate automation.

https://galaxy.ansible.com/ibm/ibm_zos_core

In addition, IBM provides a library of additional functions within the Z Open Automation Utilities product.

https://www.ibm.com/support/knowledgecenter/en/SSKFYE_1.0.0/zoautil_overview.html

Both products are no charge.

Next Steps

Continuously improving automation is an objective each of us share in my organization. At this time we are reviewing and installing the various pre-requisites needed to perform a Proof of Concept to extend Ansible automation to the mainframe. As we are still formulating use cases, I would be very interested to hear about ideas you may have for potential use cases or in general, how we can use Ansible to enhance automation involving mainframe.

Ansible is rapidly gaining acceptance to automate and orchestrate various types of activities within our organization, including z/OS. This allows organizations to extend automation and normalize skills for provisioning, deployment, orchestration into a single ecosystem wherever it makes sense. Ansible allows you to leverage existing JCL, REXX assets or use more modern capabilities such as Python scripts or z/OSMF and/or Zowe APIs.

Why Ansible?

Many teams within the organization are responsible for automation, this has been the case for decades. Each technology team may approach automation differently, for example on the mainframe we use automation to speed up system startup (IPL) or shutdown, respond to actionable messages, perform job scheduling, speed up system recovery, to name a few. These automation processes can be disparate or inconsistent since each possess their own tooling, scripting languages and user interfaces. In almost every case, mainframe automation is self-contained and does not extend across the enterprise.

What Ansible brings is a way to stitch together z/OS automation as part of an infrastructure or application pipeline. For example, short list of possible use cases includes

• Provisioning middleware (CICS regions or DB2 objects)
• Automate CICS configuration changes across 1 to many CICS regions using CICS CMCI URI modules.
• Probing an LPAR to collect information (health checks, configuration details, auditing) and push results to internal CMDB tools
• Initiate smoke tests on the mainframe after distributed system patching
• Orchestrating multiple components from 1 to many z/OS LPARs (or across sites) in a controlled and reliable way.
• Creating a git repository to store and retrieve mainframe related elements
• Provide control and automation for building development environments
• Use GIT repository for JCL and other elements

Playbook execution takes place on control node using Ansible Tower or the Ansible CLI. Most mainframe tasks will push small self-contained code to execute on the managed z/OS node.

Note that Ansible is not a replacement for the current mainframe automation tools. Tools such as IBM System Automation, Netview, job schedulers or GDPS. These products have tight integration and fast reaction to events and messages. What Ansible brings is a level of orchestration both within the many mainframe targets being managed and as a bridge between distributed applications and associated backend mainframe systems.

What z/OS functions can we do with Ansible?

The z/OS Core Collection within the Ansible Galaxy provides a number of basic functions to submit or manipulate jobs, datasets or invoke commands to help facilitate automation.

https://galaxy.ansible.com/ibm/ibm_zos_core

In addition, IBM provides a library of additional functions within the Z Open Automation Utilities product.

https://www.ibm.com/support/knowledgecenter/en/SSKFYE_1.0.0/zoautil_overview.html

Both products are no charge.

Next Steps

Continuously improving automation is an objective each of us share in my organization. At this time we are reviewing and installing the various pre-requisites needed to perform a Proof of Concept to extend Ansible automation to the mainframe. As we are still formulating use cases, I would be very interested to hear about ideas you may have for potential use cases or in general, how we can use Ansible to enhance automation involving mainframe.

Ansible is rapidly gaining acceptance to automate and orchestrate various types of activities within our organization, including z/OS. This allows organizations to extend automation and normalize skills for provisioning, deployment, orchestration into a single ecosystem wherever it makes sense. Ansible allows you to leverage existing JCL, REXX assets or use more modern capabilities such as Python scripts or z/OSMF and/or Zowe APIs.

Why Ansible?

Many teams within the organization are responsible for automation, this has been the case for decades. Each technology team may approach automation differently, for example on the mainframe we use automation to speed up system startup (IPL) or shutdown, respond to actionable messages, perform job scheduling, speed up system recovery, to name a few. These automation processes can be disparate or inconsistent since each possess their own tooling, scripting languages and user interfaces. In almost every case, mainframe automation is self-contained and does not extend across the enterprise.

What Ansible brings is a way to stitch together z/OS automation as part of an infrastructure or application pipeline. For example, short list of possible use cases includes

• Provisioning middleware (CICS regions or DB2 objects)
• Automate CICS configuration changes across 1 to many CICS regions using CICS CMCI URI modules.
• Probing an LPAR to collect information (health checks, configuration details, auditing) and push results to internal CMDB tools
• Initiate smoke tests on the mainframe after distributed system patching
• Orchestrating multiple components from 1 to many z/OS LPARs (or across sites) in a controlled and reliable way.
• Creating a git repository to store and retrieve mainframe related elements
• Provide control and automation for building development environments
• Use GIT repository for JCL and other elements

Playbook execution takes place on control node using Ansible Tower or the Ansible CLI. Most mainframe tasks will push small self-contained code to execute on the managed z/OS node.

Note that Ansible is not a replacement for the current mainframe automation tools. Tools such as IBM System Automation, Netview, job schedulers or GDPS. These products have tight integration and fast reaction to events and messages. What Ansible brings is a level of orchestration both within the many mainframe targets being managed and as a bridge between distributed applications and associated backend mainframe systems.

What z/OS functions can we do with Ansible?

The z/OS Core Collection within the Ansible Galaxy provides a number of basic functions to submit or manipulate jobs, datasets or invoke commands to help facilitate automation.

https://galaxy.ansible.com/ibm/ibm_zos_core

In addition, IBM provides a library of additional functions within the Z Open Automation Utilities product.

https://www.ibm.com/support/knowledgecenter/en/SSKFYE_1.0.0/zoautil_overview.html

Both products are no charge.

Next Steps

Continuously improving automation is an objective each of us share in my organization. At this time we are reviewing and installing the various pre-requisites needed to perform a Proof of Concept to extend Ansible automation to the mainframe. As we are still formulating use cases, I would be very interested to hear about ideas you may have for potential use cases or in general, how we can use Ansible to enhance automation involving mainframe.

Ansible is rapidly gaining acceptance to automate and orchestrate various types of activities within our organization, including z/OS. This allows organizations to extend automation and normalize skills for provisioning, deployment, orchestration into a single ecosystem wherever it makes sense. Ansible allows you to leverage existing JCL, REXX assets or use more modern capabilities such as Python scripts or z/OSMF and/or Zowe APIs.

Why Ansible?

Many teams within the organization are responsible for automation, this has been the case for decades. Each technology team may approach automation differently, for example on the mainframe we use automation to speed up system startup (IPL) or shutdown, respond to actionable messages, perform job scheduling, speed up system recovery, to name a few. These automation processes can be disparate or inconsistent since each possess their own tooling, scripting languages and user interfaces. In almost every case, mainframe automation is self-contained and does not extend across the enterprise.

What Ansible brings is a way to stitch together z/OS automation as part of an infrastructure or application pipeline. For example, short list of possible use cases includes

• Provisioning middleware (CICS regions or DB2 objects)
• Automate CICS configuration changes across 1 to many CICS regions using CICS CMCI URI modules.
• Probing an LPAR to collect information (health checks, configuration details, auditing) and push results to internal CMDB tools
• Initiate smoke tests on the mainframe after distributed system patching
• Orchestrating multiple components from 1 to many z/OS LPARs (or across sites) in a controlled and reliable way.
• Creating a git repository to store and retrieve mainframe related elements
• Provide control and automation for building development environments
• Use GIT repository for JCL and other elements

Playbook execution takes place on control node using Ansible Tower or the Ansible CLI. Most mainframe tasks will push small self-contained code to execute on the managed z/OS node.

Note that Ansible is not a replacement for the current mainframe automation tools. Tools such as IBM System Automation, Netview, job schedulers or GDPS. These products have tight integration and fast reaction to events and messages. What Ansible brings is a level of orchestration both within the many mainframe targets being managed and as a bridge between distributed applications and associated backend mainframe systems.

What z/OS functions can we do with Ansible?

The z/OS Core Collection within the Ansible Galaxy provides a number of basic functions to submit or manipulate jobs, datasets or invoke commands to help facilitate automation.

https://galaxy.ansible.com/ibm/ibm_zos_core

In addition, IBM provides a library of additional functions within the Z Open Automation Utilities product.

https://www.ibm.com/support/knowledgecenter/en/SSKFYE_1.0.0/zoautil_overview.html

Both products are no charge.

Next Steps

Continuously improving automation is an objective each of us share in my organization. At this time we are reviewing and installing the various pre-requisites needed to perform a Proof of Concept to extend Ansible automation to the mainframe. As we are still formulating use cases, I would be very interested to hear about ideas you may have for potential use cases or in general, how we can use Ansible to enhance automation involving mainframe.

Ansible is rapidly gaining acceptance to automate and orchestrate various types of activities within our organization, including z/OS. This allows organizations to extend automation and normalize skills for provisioning, deployment, orchestration into a single ecosystem wherever it makes sense. Ansible allows you to leverage existing JCL, REXX assets or use more modern capabilities such as Python scripts or z/OSMF and/or Zowe APIs.

Why Ansible?

Many teams within the organization are responsible for automation, this has been the case for decades. Each technology team may approach automation differently, for example on the mainframe we use automation to speed up system startup (IPL) or shutdown, respond to actionable messages, perform job scheduling, speed up system recovery, to name a few. These automation processes can be disparate or inconsistent since each possess their own tooling, scripting languages and user interfaces. In almost every case, mainframe automation is self-contained and does not extend across the enterprise.

What Ansible brings is a way to stitch together z/OS automation as part of an infrastructure or application pipeline. For example, short list of possible use cases includes

• Provisioning middleware (CICS regions or DB2 objects)
• Automate CICS configuration changes across 1 to many CICS regions using CICS CMCI URI modules.
• Probing an LPAR to collect information (health checks, configuration details, auditing) and push results to internal CMDB tools
• Initiate smoke tests on the mainframe after distributed system patching
• Orchestrating multiple components from 1 to many z/OS LPARs (or across sites) in a controlled and reliable way.
• Creating a git repository to store and retrieve mainframe related elements
• Provide control and automation for building development environments
• Use GIT repository for JCL and other elements

Playbook execution takes place on control node using Ansible Tower or the Ansible CLI. Most mainframe tasks will push small self-contained code to execute on the managed z/OS node.

Note that Ansible is not a replacement for the current mainframe automation tools. Tools such as IBM System Automation, Netview, job schedulers or GDPS. These products have tight integration and fast reaction to events and messages. What Ansible brings is a level of orchestration both within the many mainframe targets being managed and as a bridge between distributed applications and associated backend mainframe systems.

What z/OS functions can we do with Ansible?

The z/OS Core Collection within the Ansible Galaxy provides a number of basic functions to submit or manipulate jobs, datasets or invoke commands to help facilitate automation.

https://galaxy.ansible.com/ibm/ibm_zos_core

In addition, IBM provides a library of additional functions within the Z Open Automation Utilities product.

https://www.ibm.com/support/knowledgecenter/en/SSKFYE_1.0.0/zoautil_overview.html

Both products are no charge.

Next Steps

Continuously improving automation is an objective each of us share in my organization. At this time we are reviewing and installing the various pre-requisites needed to perform a Proof of Concept to extend Ansible automation to the mainframe. As we are still formulating use cases, I would be very interested to hear about ideas you may have for potential use cases or in general, how we can use Ansible to enhance automation involving mainframe.