 Quick one-off changes: Edit a job instance in the plan - If you look at the typical time line of a job, you've got a modelling phase where you create your job definition in the database, the submission of the job into the current plan, and then according to the schedule, the job execution until the job completes and reports its status.  What you can do now… In a best-case scenario, all goes well from start to finish, but there are times when you might need to make a one-off quick fix either before the job runs or after it has already run and rerun it to resolve an error or address an issue. You can modify a job definition in the database whenever and as many times as you want. However, there are times when you need to make changes to the job definition, but it has already been submitted into the plan and runs as is. This results in extra work and lost time in updating the definition in the database and then getting it into the plan to run. Maybe you just need to fix an error in the command, script, or logon name, or maybe you know a workstation is down and want to switch to a different one. The same information present in the job definition in the database can be edited directly in the plan. …and what you can do after installing 9.4 Fix Pack 3! Workload Automation version 9.4 Fix Pack 3, among other enhancements, introduces two extra opportunities in the timeline of your job to make quick one-off changes. You can edit the job definition on-the-fly before it runs, or rerun a job with an updated definition.  This added flexibility in modifying the job definition directly in the plan and rerunning it ensures job flow continuity. It can be done simply and easily from: Normally, when a job ends in error, it requires the intervention of the Scheduler or Application Support, but now, even the operator can quickly modify it and then rerun it to recover.  The possibility to edit the job definition is available for jobs that have not yet started or for jobs that have already completed their execution through a Rerun operation.  When re-running a job, you can click on “Edit Job”…  …look at the original definition…  …and change it according to your needs. In this example, a portion of a script is removed from the original definition and a lightweight version of the script is re-run instead. With this simple operation, a lot of unnecessary steps are bypassed! This is a very common scenario if your scripts performed a set of actions successfully, but it failed at a certain point. If you don’t want to re-execute the full script, this is the best way to do it! If you’re wondering if you can edit the definition of a job executable plugin (RESTful, Database, Amazon or Azure provisioning, etc.) … well, yes! You can do it as well, customizing its original properties during a Rerun or Edit Job operation.  RESTful plugin  Database plugin  UNIX plugin It's especially useful when failures occur in a Scheduling environment with the distributed agent for z/OS, where you can retrieve the JCL stored in the remote data set on the z/OS system hosting the agent, edit it, and then rerun the job.  z/OS job plugin Enjoy this video and see it in action!
0 Comments
Your comment will be posted after it is approved.
Leave a Reply. |
Archives
May 2022
Categories
All
|
RSS Feed