Ansible Core v1.12.0 is released and comes with support for z/OS 3.1🎄🎄🎄!
🎄🎄🎄 Hello everyone! 🎄🎄🎄
December is here, and the holiday spirit is in the air! As we wrap up the year, we’re thrilled to share our special gift to the community: the brand-new release IBM Ansible z/OS Core v1.12.0 release🎁🎁, this is our first release that supports z/OS 3.1!! Don't worry, we still support 2.5, in fact, this release will support z/OS 2.5 - 3.1!
This new release is packed with 24 bugfixes and 8 enhancements to make your automation experience even better. It's our way of saying thank you for your continued support and dedication throughout the year.
Enhancements
The job type modules(zos_job_output, zos_job_query, zos_job_submit
) now return a content_type, this is important when you want to differentiate what type of job you are interacting with. The types returned can be:
- APPC for a APPC Initiator.
- JGRP for a JOBGROUP.
- JOB for a Batch job.
- STC for a Started task.
- TSU for a Time sharing user.
- ? for an unknown or pending.
Another important change has been how the modules handle unpresentable characters. In recent versions of ansible-core, you may have seen a warning similar to:
[DEPRECATION WARNING]: Non UTF-8 encoded data replaced with "?" while displaying text to stdout/stderr,
this is temporary and will become an error. This feature will be removed in version 2.18.
In ansible-core version 2.18, it will no longer substitute unpresentable character leaving collections to handle them. In this release, if any module encounters an unpresentable character, it will be replaced with the 'replacement character' (�), found in the Unicode standard at code point U+FFFD.
There has been a slight change in the behavior of the zos_backup_restore module where if the operation is set to restore and the hlq is not provided, the original high level qualifiers in a backup will be used for a restore. Previously, the module did not support using the original high level qualifiers and applied the same HLQ to all restored data sets.
Module zos_operator now supports case sensitivity, if you are running operator commands that are case sensitive, you can now maintain case sensitivity with option case_sensitive=true. This is helpful in cases where a command is interacting with Unix System Services (USS) , for example:
ibm_zos_core.zos_operator:
cmd: "S MYPROC,JOBNAME=MYPROC1, CONF=/usr/myproc/config'"
This is the complete list of enhancements:
zos_backup_restore
- Default behavior for module option **hlq** changed. When option **operation** is set to **restore** and the **hlq** is not provided, the original high level qualifiers in a backup will be used for a restore.
zos_job_output, zos_job_query, zos_job_submit
- Has added the address space type for a job returned as content_type in the module response.
zos_mvs_raw
- Updates the stdout and stderr when an unknown, unrecognized, or unrepresentable characters with the 'replacement character' (�), found in the Unicode standard at code point U+FFFD.
zos_operator
- Has added the option case_sensitive, allowing the module to control the commands case.
zos_script
- Updates the stdout and stderr when an unknown, unrecognized, or unrepresentable characters with the 'replacement character' (�), found in the Unicode standard at code point U+FFFD.
zos_tso_command
- Updates the stdout and stderr when an unknown, unrecognized, or unrepresentable characters with the 'replacement character' (�), found in the Unicode standard at code point U+FFFD.
Bugfixes
Some modules had many bugfixes, zos_copy
would fail if the user did not have Universal Access Authority for SAF Profile MVS.MCSOPER.ZOAU and SAF Class OPERCMDS, that is still the case because these profiles are needed. Now, the module will show an informative error message. Also, temporary remote folders used in the module were not modifiable, so if your /tmp/ folder didn't have enough space or the user didn't have write access the operation would fail! Fix now lets you modify the temporary remote folder by setting remote_tmp in the Ansible configuration file.
The latest updates to the zos_mvs_raw
module bring some much-needed improvements. First, the base64
sub-option under return_content
now properly delivers DD output as Base64, ensuring the expected functionality. Additionally, the module now returns the correct return code from programs instead of always defaulting to 8 on failure, giving you accurate feedback. Lastly, we’ve addressed a false positive issue where the module would succeed even if a program failed with a non-zero return code when verbose was false.
You can read a list of all the bugfixes here:
zos_apf, zos_archive, zos_blockinfile, zos_copy, zos_data_set, zos_encode, zos_fetch, zos_lineinfile, zos_mount, zos_unarchive
- module option tmp_hlq was previously ignored and default values were used. Now the module uses the value set in the option.
zos_backup_restore
- When a recoverable error was encoun encountered and
recover = True
, the module would fail. The change now allows the module to recover.
zos_blockinfile
- when the modules marker_begin and marker_end were set to the same value, the module would not delete the block. Now the module requires the marker_begin and marker_end to have different values
zos_copy
- module would fail if the user did not have Universal Access Authority for SAF Profile MVS.MCSOPER.ZOAU and SAF Class OPERCMDS. Now the module handles the exception and returns an informative message.
- module would ignore the value set for remote_tmp in the Ansible configuration file. Now the module uses the value of remote_tmp or the default value ~/.ansible/tmp if none is given.
zos_find
- Module would not find VSAM data and index resource types. Fix now finds the data and index resource types.
- Module would not find a VSAM cluster resource type if it was in use with DISP=OLD. Fix now finds the VSAM cluster.
zos_job_output
- Module would raise an invalid argument error for a user ID that contained @, $, or #. Now the module supports RACF user naming conventions.
-
zos_job_query
- Module did not return values for properties system and subsystem. Now the module returns these values.
- Module would raise an invalid argument error for a user ID that contained @, $, or #. Now the module supports RACF user naming conventions.
zos_mvs_raw
- Module sub-option base64 for return_content did not retrieve DD output as Base64. Now the module returns Base64 encoded contents for the DD.
- Module would return the stderr content in stdout when verbose was true and return code was 0. Fix now does not replace stdout content with stderr.
- Module would obfuscate the return code from the program when failing returning 8 instead. Fix now returns the proper return code from the program.
- If a program failed with a non-zero return code and verbose was false, the module would succeed (false positive). Fix now fails the module for all instances where a program has a non-zero return code.
zos_script
- Module would only read the first command line argument if more than one was used. Now the module passes all arguments to the remote command.
Known Issues
Lastly, we've identified some issues that were not possible to fix in this release, either because of priorities or complexity.
zos_job_submit
- when setting 'location' to 'local' and not specifying the from and to encoding, the modules defaults are not read leaving the file in its original encoding; explicitly set the encodings instead of relying on the default.
- when submitting JCL, the response value returned for **byte_count** is incorrect.
zos_apf
- When trying to remove a library that contains the '$' character in the name for an APF(authorized program facility), the operation will fail.
zos_find
- When trying to find a VSAM data set that is allocated with DISP=OLD using age filter the module will not find it.
Stay tuned for more details, and we hope you enjoy this little treat as much as we enjoyed creating it for you! Happy holidays and happy exploring! ✨
About the Authors
Oscar Fernando Flores Garcia is an IBM z/OS Ansible Core software engineer with over 6 years of experience who designs and develops many of the collections modules and responsible for many of the product releases.
Demetrios Dimatos is the IBM z/OS Ansible Core Senior Technical Lead with 17 years mainframe experience and over 20 years of development experience; having led multiple products ranging from client server technologies, administration consoles, IBM Open Platform (Hadoop - HDFS, MapReduce, Yarn) and Spark, Linux, and Solaris kernel development.
Image from Amanda Stephens
The Development Team
Without the development team, this would not be possible. I would like to thank the amazing team who work with passion and perseverance on this project.
- Rich Parker
- Ketan Kelkar
- Oscar Fernando Flores Garcia
- Ivan Alejandro Moreno Soto
- Andre Marcel Gutierrez Benitez
Resources
IBM Ansible z/OS core on Galaxy
IBM Ansible Core Collection Repository on GitHub
IBM Ansible Core Collection on Automation Hub
Red Hat® Ansible Certified Content for IBM Z documentation