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:
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.
0 Comments
Your comment will be posted after it is approved.
Leave a Reply. |
Archives
October 2024
Categories
All
|