Cross Dependencies are no longer a pain on IBM Workload Scheduler for z/OS

When IT customers deal with scheduling on mainframe, often it can happen that their workload runs in more than one z/OS, sometimes with no interactions among these environments for many reasons. Anyway, in many cases there is the need of conditioning the start of a z/OS batch procedure if and only if another job or chain completed successfully in a totally different z/OS system.
​

The same thing happens with distributed environments, even if an end to end implementation can solve the issue of linking a mainframe job with a distributed job. 

What happened in the past when an IT scheduling guy was faced with the painstaking task of creating a dependency between jobs on a z/OS system with other ones on a remote z/OS? This guy had to start thinking to a non-standard workaround, where the most common one was simulating a file transfer initiated by the first job to the remote system, where the second job recognized the event and was then able to start. This had also other strong implications, security for example or synchronization. 

This type of pain completely ended with IBM Workload Scheduler for z/OS in the last two years, so the need to use workarounds or in-house solutions, often difficult to maintain, allowing to create dependencies among different current plans running in totally separated IWSz Controllers, disappeared. Now this is possible and it is a native functionality of IBM Workload Scheduler. Moreover, this is also extremely easy to implement, and this is what I would like to show here, also because a customer just asked me to give advice on this, so I thought a blog post would have been useful also for other customers with the same need. 

I will provide here an easy example of how it is possible to create a cross dependency between two jobs running on two different IWSz environments. So, suppose we have two IWSz Controllers, totally separated one from the other one, and we would like to give a target job, running on a local Controller, a predecessor which resides on a remote Controller. For making your reading easier, I will put in blue common objects, in green all objects belonging to the main remote controller, in red all those related to the secondary local controller. 

First of all, we need to make the two Controllers communicate inside the IWSz architecture, and this is done with two parallel definitions in the respective IWSz PARM libraries.
​

Main Controller 
    ROUTOPTS HTTP(ZT01CROS:'10.3.20.2'/531/Z) 
    HTTPOPTS TCPIPJOBNAME('TCPIP') 
        HOSTNAME(10.3.20.1) 
        HTTPPORTNUMBER(521) 
​
Secondary Controller    
  ROUTOPTS HTTP(ZT01CROS:'10.3.20.1'/521/Z) 
  HTTPOPTS TCPIPJOBNAME('TCPIP') 
        HOSTNAME(10.3.20.2) 
        HTTPPORTNUMBER(531) 
​

The main controller, which owns the job that needs to be a predecessor, is located remotely to the secondary controller, which is the local one and owns the target job. ZT01CROS represents the common destination. Then we have the two z/OS IP addresses with corresponding ports, which need to cross fit, how you can see. The Z represents the fact this is a full z/OS example. Consider in fact that the cross dependencies functionality works with all types of engines, independently they are mainframe or distributed. 

Of course these definitions can be activated by stopping and starting both Controllers, but the activation is possible also real time with the console command F OPCC,RFRDEST, where OPCC is the Controller subsystem name, issued for both IWSz Controllers. 
​
After the activation, we are ready to define the cross dependency. Suppose we would like to assign to the target job TESTVAR, on the secondary controller, a predecessor which will be BKPJS10 running on the main controller. 

First thing to do is create a remote workstation on the remote controller, as shown below:

You can see that the defined workstation has the same destination previously defined in the IWSz PARM. You can also notice that: 

• WORKSTATION TYPE=R 
• REMOTE ENGINE TYPE=Z 

Once defined the workstation, we only need to create in the secondary IWSz a remote BKPJS10 predecessor and map it to the main BKPJS10 job. IWSz will use a mirroring mechanism. The remote job BKPJS10 is a dummy operation and will be the real predecessor of the target job TESTVAR. The status of this dummy job BKPJS10 will be completely managed by the corresponding status of the real job BKPJS10, running on the main controller. When the real job completes, at the same synchronized time IWSz completes the corresponding dummy job, making the target job TESTVAR regularly start. 

​Let’s see how to define this simple scenario on both controllers.  
​
On the secondary engine

On the main engine

As you can see, the remote workstation WC01 has been used to define the mirror dummy job. The common destination specified in the PARM definitions ensures that the mirroring mechanism takes effect. 

I hope the initiative to write this blog post coming from a customer request can be useful also for other customers running our IBM workload automation solution on z/OS. I am also interested to know if there are any other possible issues requiring specific workarounds or in-house customizations which could be better to address through a native functionality. Please write me for any question, follow me on Twitter and LinkedIn.

Nico Chillemi
Executive IT Specialist

Domenico Chillemi, known as Nico, is an Executive IT Specialist in IBM Italy, with the role of Europe IOT Technical Leader for zSystems IT Service Management and Security technical sales. He is also the IBM Italy Technical Specialist Profession Leader, very careful to colleagues career and eminence. He belongs to the IBM Academy of Technology (AoT) Leadership Team as AoT Core Team member and also to the IBM zChampion team, leading all zSystems initiatives inside the IBM Academy of Technology. His main expertise is Workload Automation, especially in mainframe and end to end, and he tightly collaborates with HCL Technologies, being one of the IBM contacts point for customers with HCL. Moreover, he has also a strong knowledge of zStorage tools, System Automation and Security on zSystems.