-
Notifications
You must be signed in to change notification settings - Fork 147
Description
Hi,
For information, I create an Idea for an evolution of DBB API:
DBB API - Manage a return code for each MVSExec for a chaining sequence in an MVSJob.
Note: I also suggest to open a "Discussions" page on this site, as made for IBM/dbb-zappbuild site.
Hi,
The MVSJob API allows you to chain MVSExec objects and execute them in sequence until an RC value exceeds the specified maxRC value.
Sample from zAppbuild BMS.groovy:
def rc = new MVSJob().executable(copyGen)
.executable(compile)
.executable(linkEdit)
.maxRC(maxRC)
.execute()
This way of declaring build steps is very efficient and greatly simplifies the coding of the build script.
But this assumes that all MVSExec steps have the same value of maxRC, which is not necessarily true.
I suggest being able to associate a maxRC value on each MVSExec, which MVSJob would test to decide whether or not to continue on the next MVSExec step.
This maxRC value would be declared when creating the MVSExec object:
MVSExec step1 = new MVSExec()
...
step1.maxRC = 4
MVSExec step2 = new MVSExec()
...
step2.maxRC = 0
MVSExec step3= new MVSExec()
...
step3.maxRC = 4
def rc = new MVSJob().executable(step1).executable(step2).executable(step3).maxRC(8).execute()
MVSJob stop execution if step1 has a RC > 4 or if step2 has a RC > 0 or if any step has a RC > 8.
The declaration of a maxRC at MVSJob level is not necessary but it can be used as a default value for MVSExecs which would not declare a maxRC.
The return code indicated at the MVSExec step level takes priority over the return code indicated at the MVSJob job level.
This also makes it possible to reproduce what can be done with a classic JCL by declaring a general condition at the level of the job and by specifying conditions at the level of each step.