Can you have your desired number of Workload Automation (WA) agent, server and console instances running whenever and wherever? Yes, you can!
Starting from the Workload Automation version 9.5 fix pack 2, you can deploy the server, console and dynamic agent by using Openshift 4.2 or later version platforms. This kind of deployment makes Workload Automation topology implementation 10x faster and 10x more scalable compared to the same deployment in the on-prem classical platform.
This Blog aims to showcase a Case Study on how Travel Expense Reimbursement can be evaluated in a company using Workload Automation. Typically every company would have a Portal where Employees would login and report all expenses made against a Travel and the same is reimbursed based on their Eligibility .
Enforce Workload automation continuous operation by activating Automatic failover feature and an HTTP load balancer
How important is that your Workload Automation environment is healthy, up and running, and there are no workload stops or delays? What happens if your Master Domain Manager becomes unavailable or it is affected by downtime? What manual recovery solution you must do when it happens? How can I distribute simultaneously requests to several application servers in my configurations if my primary server is drowning? How can I hourly monitor the workload automation environment healthy in an easy way? How can I have an alerting mechanism?
No matter if your environment is based on rock solid z/OS controller or on light weight and easily scalable docker instances, or if your distributed, on premises master and backup master are rocking your workload as fire and water.
Earth, wind, water and fire… if you want to have control over each element you need the fifth spirt: your custom dashboard!
It’s easy to create and customize your dashboard to have control over every single important aspect for you and your organization at a glance.
Each dashboard is composed by several data sources and widgets that can be customized and combined together in the new era of dashboards.
But you can also optimize your dashboard to monitor different kinds of environments all together. Let’s see how it works.
Keeping track of all the changes and workflows and be aware of unexpected behaviors can be challenging in complex Workload Automation environments, but don’t worry, we’ve got you covered!
We are proud to announce you the new Era of Dashboards!
Workload Automation on z/OS (IBM Z Workload Scheduler or HCL Workload Automation for Z) allows users to centrally control all the automation processes providing capabilities to facilitate the operations for mainframe users.
You can have the Workload Automation sending an email to a recipient or list of recipients when an alert condition occurs.
With the SPE of May Z Workload Scheduler (Zws) provides the possibility to automatically insert into the submitted JCL customized SYSAFF and CLASS JOB card keywords.
All z/OS users know very well that SYSAFF card is used to force the execution of a job on the indicated systems and that CLASS assigns specific characteristics to the job, like holding, time and even return code handling logic (JOBRC).
The point is: why this is important for Zws users?
If you want to avoid a potential business disruption in your Workload Automation environment, you should leverage the Master/Backup Master configuration. But, what happens if the RDBMS connected to Workload Automation crashes?
In this article, we will describe how to manage both Workload Automation components and DB2 HADR to allow business continuity during a disaster event.
Before knowing about our plugin use cases and how it benefits to our Workload automation users, let us have little insight about what is SAP HANA Extended Application Services (XS).
SAPHanaXs Engine is a key aspect of the SAP Hana Platform. It provides a comprehensive platform for the development and execution of micro-service-oriented applications, taking advantage of SAP HANA's in-memory architecture and parallel execution capabilities.
A common need, coming from customers, is the possibility to list operation’s Successors in the Database, as it happens in the Current Plan (after the operation is loaded in the plan). At moment, through WAz ISPF Dialog, it is possible to access only to Predecessor list for operations in the Database.
The WAPL (Workload Automation Programming Language) interface allows to easily get over this limitation in WAz, giving the possibility to see successors to a job in the database, including external ones.