zAppbuild enhancement - isSQL scanning in Copybooks about dbb-zappbuild HOT 6 CLOSED

Sorry, don't like that solution. If it's implemented then I would like to have a choice, do the spin through or not...
Doesn't it work if you set the isSQL-option in file.props, or do you find it a bit messy ?

from dbb-zappbuild.

Good point. Setting this in a prop file hard codes it for all programs in the project. Not ideal. With spinning across dependencies we can be more selective.

from dbb-zappbuild.

No, it's set on module-level.
OK, so you have your SQL-code in a lot of copybooks right ? More than 50% of your code, otherwise you will 'pay' for it in every build instead of dealing with it only in the modules involved...

from dbb-zappbuild.

Kind of - yes. Plus I worry about always passing the "SQL" compiler options for non-DB2 programs. I'm not sure thats a good practice.

from dbb-zappbuild.

Probably, I have missed something in the discussion. You can overwrite the isSQL property on a file level. If you have a couple of programs, then you can add these files to this list. If you have naming conventions to indicate, you can also use wildcards. Here is an example for isCICS from the Mortgage sample:

Within buildUtils.isSQL, this file property 'overwrite' is taken into consideration.

I assume, your previous build environment carries these information. Mapping the programs of type 'db2', with an extract of all the pgms in your dbb collection, can give you the delta where you need to set the isSQL pgm in file.properties.

The proposed enhancement is expected to be expensive, because you would need to scan / query all copybooks referenced for the given COBOL file (for a userBuild and pipelineBuild).

from dbb-zappbuild.

Just a side comment pointing out that we already scan all copybooks referenced by a COBOL program so that we can identify and resolve them in the local Git repository to copy them to the copybook data set. This is done in BuildUtilities.copySourceFiles. It even creates a list of dependencies (https://github.com/IBM/dbb-zappbuild/blob/development/utilities/BuildUtilities.groovy#L81) that we could return from the method and check to see if any are marked isSQL.

I was mistaken. The dependency resolver returns physical dependencies which do not contain the isSQL flag. Looks like we would have to scan the dependencies a second time to get the logical files. This might be a good candidate for a stand alone sample in the DBB samples repository that customers that need it can integrate in their copy of zAppBuild.

from dbb-zappbuild.