Automate CA Endevor Package Shipments with Zowe CLI
Editor: Rose Sakach
{Ecosystem} In our day-to-day lives without even realizing it, we quite often experience a phenomenon that I will call an automatic response. This simply means that when one activity occurs there is an expectation that another must immediately follow. For example, in casual, friendly conversations when person “A” says “knock-knock”, it is highly anticipated that person “B” will respond with — “who’s there?” Similarly, as an automobile operator settled in the driver’s seat, after pressing the “Start” button (or in some models “turning the key” on the ignition), it is expected that the automobile engine starts running immediately. If we take this phenomenon to the world of technology and specifically to mainframe software change management, when an Endevor Package is marked with a status of “executed” i.e. completes the action of delivering the referenced assets to a local target location — it is reasonable to expect that same activity to automatically initiate the process of delivering them to all pre-defined destinations — not just the local ones. This long-standing, cross-LPAR deployment feature is leveraged to schedule mainframe software deliveries and is known as Endevor Package Ship. For a variety of reasons, many organizations prefer to manage these activities with mainframe deployment teams responsible for synchronizing these changes with enterprise orchestration tools. But, with the introduction of Zowe, this preference should be re-evaluated.
The Open Mainframe Project’s Zowe CLI Helps To Automate Endevor Package Ship
Before Zowe CLI, the Package Ship process could be initiated by an Endevor User Exit but this limited the orchestrator to on-host tooling, eliminating its ability to incorporate mobile, cloud, and distributed assets in the deployment process. For this reason, many customers retain a proven, traditional procedure relying on manual intervention at three distinct points: first — to determine if a Package should be Shipped, second — to decide where to Ship, and third — to manually initiate the Shipment process. Zowe CLI changes this equation. How? Simple. It enables off-host initiation of Endevor Package Shipments. Why does this matter? Because it does more than automate the manual steps, it allows mainframe deployments for all destinations to be orchestrated along with other non-mainframe application assets. We can now achieve the desired and expected deployment results with what we call the Automated Endevor Package Shipment Configuration. This is a collection of items, including Zowe CLI scripts, JCL, REXX code and the like that have been made available to you through a sample script repository.
How it Works
Let’s break down the process. We make use of Zowe CLI, a Table of Rules and a Log File. We begin with zos-tso issue command for a package in ‘EXECUTED’ status. Next, we use other components included with the Automated Endevor Package Shipment Configuration to parse the Package content and determine whether any Shipments are necessary. This is achieved by scanning the Table of Rules for an Endevor inventory match and then to reading the Destination field for Package Shipments. Finally, a Package Shipment job is automatically submitted for every defined Destination.
The Table of Rules is an Endevor element that is version-controlled and secured. Zowe CLI zos-tso Endevor SCL commands are also used to maintain the contents. The commands are included the Automated Endevor Package Shipment Configuration. The picture above depicts the Table. Each rule is represented as a record (row) and consists of fields that contain values or wild-carded masks* which represent the:
· Endevor environment
· Endevor Stage
· Endevor System
· Endevor Subsystem
· Shipment Destination
*For example, if you are supporting dynamic environments from which you ship to remote locations, you can use “TEST*” as an environment entry in the Rules table. If the “Deploy to Test” feature is active and its target locations are associated with remote destinations, you can name the target as a Subsystem in the Rules table. In every case, any Endevor Package that impacts an Endevor inventory area referenced by a shipment rule automatically initiates a package shipment.
A value on each row of the Rules Table names the Destination for a package shipment. When the content of a Package matches the Endevor Environment, Stage, System, and Subsystem values on a row of the table, a Package Shipment job is submitted for the destination named on that row. The submitted JCL is the very same JCL Endevor submits when Package Shipments are initiated from a traditional Endevor ISPF panel.
The process includes flexibility to manage the timing of a Shipment. A “TYPRUN” value on the Rules table (not shown in the simulated table above) serves to indicate that a job is to be submitted with TYPRUN=HOLD on the job card. This allows shipment jobs to be submitted automatically, but to remain on HOLD until either manual intervention or another automated service releases the job for execution.
If your organization supports multiple Endevor images, a configuration component enables you to specify details for each LPAR. For example, Endevor dataset names, job class and job accounting information may vary by LPAR. The name of the shipment Rules table may be different on each LPAR to accommodate these situations.
The configuration supports an output Log file for each LPAR. It tracks submissions of automated shipments, recording information such as the Package name, Destination, along with the date and time of each job submission. The Log file also plays a role in Package Shipment scheduling. In many cases, Package Shipment jobs are initiated the instant the associated Package’s status is changed to “EXECUTED”. However, there are use cases where postponement or more sophisticated scheduling is required. In addition to collecting details of past shipments, the Log may contain details required for future Package Shipments. These include: Package Name, Destination, date and time for future package shipments. A simple adjustment to your existing Endevor Package “Sweep” Job — a term we use to describe the scheduled Job responsible for ensuring the timely submission of Package Executions — can also be given the task of submitting scheduled Package Shipments. This is achieved by adding a Jobstep which uses one of the components of the configuration to scan the log file, and when the scheduled date and time has arrived, it triggers the Package Shipment and updates the entry on the log file indicating the activity has occurred. Users interested in viewing completed and scheduled Package Shipments can issue simple, interactive Zowe CLI commands referencing the Log file or the Endevor Package.
One Size Does Not Fit All
This solution is not designed for all consumers. Managing the Rules table, automated logging and the scheduling of Package Shipments may be considered unwarranted for organizations with single-destination and non-complex Shipments. For these cases, a less demanding, automated solution is available with simpler configuration requirements. The Rules table and logging of submissions are not included with this solution.
Go Ahead and Script It
Regardless of which solution you chose, once you have it configured you can initiate the process of automating Package Shipments from orchestration tools like Jenkins, Bamboo, Automic® Continuous Delivery Automation, and IBM UrbanCode. How would you do this? By scripting in the appropriate Zowe commands. Your DevOps Engineer will know where. Please note: the commands required for this process are not direct CA Endevor commands and therefore do not require Web Services nor the CA Endevor plug-in for Zowe CLI. This means the process is viable for a wide range of Endevor releases.
Ready to give it a try? Complete the simple setup process outlined in our Broadcom sample scripts repository and configure your Rules Table. Next, issue these commands to create zowe profiles, and initiate the Package Shipment Automation:
zowe profiles create zosmf-profile profilename –host hostname --port portnumber --user username --password password --ru falsezowe profiles create tso-profile profilename --account accountnumber --logon-procedure TsoLogonProcedure --regionSize Regionsizezowe zos-tso issue command "PKGESHIP 'packagename'"
Change profilenames, username, password, hostname, portnumber and other values to fit your environment. For Example:
zowe profiles create zosmf-profile SYSA --host 11.999.99.100 --port 1443 --user myuserid --password ?????? --ru falsezowe profiles create tso-profile SYSATSO --account 12345 --logon-procedure IZUFNDVR --regionSize 8000zowe zos-tso issue command "PKGESHIP 'MOVE2PRODPKG'"
PKGESHIP is the name of a REXX component in the configuration. For the package name in the command, zero-to-many package shipments are initiated.
So, if you have been anxious to incorporate Package Shipment Automation in with your Enterprise DevOps tooling, wait no more! Who’s there? Automated Endevor Package Shipment Configuration AND Zowe CLI — waiting for you to give them a try!
To download the core Zowe CLI visit the community site https://www.zowe.org. Alternatively you can visit the Broadcom managed site Broadcom Distribution of Zowe to obtain the core Zowe distribution as well as the CA Endeavor plugin.
Find more CA Endevor Zowe CLI Sample Scripts here: Broadcom sample scripts repository
Finding out more
If you enjoyed this blog checkout more Zowe blogs here. Or, ask a question and join the conversation on the Open Mainframe Project Slack Channel #Zowe-dev, #Zowe-user or #Zowe-onboarding. If this is your first time using the OMP slack channel register here.
Zowe is owned and managed by the Open Mainframe Project which is a Linux Foundation project.
