Question | Calling a Db2 batch program using the MVSExec API

[FALLAI-Denis]

Hi,

Is it possible to execute a Db2 batch program, in particular a COBOL program, using the MVSExec API?

Should the program be prepared in a particular way (mode of attachment of the plan/package)? Does the bind package/plan need to be done in a particular way?

Are there any implementation examples? either at the IBM DBB level or at the JZOS level?

Thanks.

[dennis-behm]

@FALLAI-Denis ,

Like you would do in the JCL world as :

//jobname JOB USER=MY DB2ID
//GO EXEC PGM=IKJEFT01,DYNAMNBR=20
//STEPLIB DD DSN=prefix.SDSNEXIT,DISP=SHR
//        DD DSN=prefix.SDSNLOAD,DISP=SHR
⋮
//SYSTSPRT DD SYSOUT=A
//SYSTSIN DD *
DSN SYSTEM (ssid)
RUN PROG (SAMPPGM) -
  PLAN (SAMPLAN) -
  LIB (SAMPPROJ.SAMPLIB) -
  PARMS ('/D01 D02 D03')
END
/*

IKJEFT01 cannot be invoked from MVSExec. (Let me cross check with the DBB team)

[FALLAI-Denis]

Hi @dennis-behm,

If we cannot execute a Db2 program via the IKJEFTxx program, we must be able to call it directly, but then we must manage the allocation of the plan in the program itself... not simple but doable...
--> switch to call attachment facility (CAF) instead of TSO attachment facility

[dennis-behm]

Hi @FALLAI-Denis,

What is the use case for calling the Db2 program? This does not sound like a typical scenario for a build framework implementation to start db2 programs; you might enter a grey zone and leave the area for what Dependency Based Build is designed for.

To perform some automation you might just want to use the JobExec or even look into IBM Z Open Automation Utilities.

[reachsenthilnathan]

Hi @FALLAI-Denis , I am Senthil Nathan - Product Manager for DBB. I have the same question as Dennis on the need for a DB2 program execution in a build framework. Commenting here to get updates on the thread.

[FALLAI-Denis]

Hi,

Our CI/CD tool chain takes place in three main stages:

• Build
• Package
• Deploy

At the deployment stage we want to keep up to date the state of the components installed on an environment.
For this we want to update the data that describe the configuration of the target environment.

To do this, we want to use the capacities of Groovy and the DBB API which allows us to do these treatments in SSH mode (STC mode or TSU mode) rather than launching jobs (JOB mode) which will inevitably be subject to queuing (jes queue management) not compatible with our need for fluid chain of operations.

Note that we have made a first version that uses files (GDG), but the DBB MVSExec API does not manage competing access to files: if a file is reserved (locked) by another processing, execution MVSExec triggers an error (BPXWDYN more precisely) and the treatment is not carried out, (no wait on locked resource). For this problem I will open another request.

It is to avoid this contention problem on files that we want to use DB2 tables rather than files.

[reachsenthilnathan]

Is this deploy - deploy at the user build / dev environment level or does this deploys to controlled environments like production as well?

Irrespective of that question, would JCLExec (In 2.0.1, JobExec) work? https://www.ibm.com/docs/en/dbb/2.0?topic=apis-zos-commands#jclexec

[FALLAI-Denis]

Hi,

Deployment concerns test and acceptance environments as much as production.

The processing that we want to implement is in fact a step upstream of the deployment itself for its preparation. It posts the actual installation request which will be processed asynchronously in shifts at regular intervals.

This is a process which analyzes the manifest (list of components and their metadata) contained in a package and the current state of the deployment target environment, in order to calculate the gap of components necessary and sufficient to install (do not reinstall components already in place and not modified, our packages contain the scope of a project and the project can be deployed several times in a row to provide additions or corrections).

Due to the fact that MVSExec does not support concurrent access to files (1708 error in BPXWDYN?), we have chosen to manage the state of the target environment in Db2 tables.

This preparatory treatment is triggered from XL Release, with a human operator in charge.
For this reason we want a fast, almost immediate response time, which cannot be guaranteed by submitting a job (with delay taken care of by a jes2 queue), and we prefer to use SSH scripts and in this case a development carried out in groovy and using the DBB APIs to submit treatments which in this case function like an STC or a TSO session.

[FALLAI-Denis]

Hi,

In zAppbuild, bindPackage in bindUtilities use TSOExec to call a Db2 program. Is it this solution what we have to consider?

https://github.com/IBM/dbb-zappbuild/blob/main/utilities/BindUtilities.groovy

[FALLAI-Denis]

PS: The TSOExec solution does not seem to meet our needs....

cf. https://www.ibm.com/docs/en/dbb/2.0?topic=apis-zos-commands#ispfexec-and-tsoexec