Copybook within Copybook

[mhardin18]

I'm not sure if I should make this a discussion or an issue. But I would like some advice on how to handle this scenario.

Cobol Program A includes a COPY statement pulling in copybook B. Copybook B also includes a COPY statement pulling in copybook C.

This is failing for user builds. I haven't gotten pipeline builds with full scans completed for this implementation. I can force it somewhat with using the dependency file, but this is not ideal.

So what is the best practice for this situation for both user builds and pipeline builds?

[FALLAI-Denis]

Hi

Is this issue specific to userBuild or also apply to impactBuild / fullBuild ?

How userBuild is trigered ? From IBM Z Open Editor ? From a command line ?

What is the content of the workspace ? Is it a git repository cloned on USS or just a folder populated with some elements ? Does needed imbeded copybooks accesible in this workspace ? Does application-conf and properties for searching copybooks configured according this workspace ?

[M-DLB]

The collection in DBB should contain dependencies references to copybooks B and C. So for impact builds performed through the pipeline, the sources should be scanned first and the collection correctly populated. For User Build, I think the IDz plugin (assuming you're using this one) is able to recursively find all the dependencies. Which IDE are you using for User Builds?

[mhardin18]

Thanks for the responses. This is only affecting user builds. User builds are being performed using IDz. It is not picking up the nested copybooks. Is there something in IDz that needs to be configured for this?

[FALLAI-Denis]

Hi,

I understand that the problem is the absence of "non first level" copybooks to successfully complete the userBuild. The problem is not to do a impactBuild triggered by the modification of a copybooks, especially since the userBuild managed by zAppbuild does not make any access to DBB metadatastore (but access to DBB API for scanning COBOL source for copybooks references search). UserBuids are completely independent of DBB metadatastrore, (but dependant of DBB API).

I understand that the problem encountered is that IDz would not detect the "non first level" copybooks and do'nt bring them up to the workspace on USS for the userBuild to succeed.

When editing COBOL code, does IDz find and display nested copybooks?

I don't know how IDz works but I know how IBM Z Open Editor works (and IBM Z Open Editor is apparently a subset of IDz features). For the userBuild to succeed from IBM Z Open Editor, you must: 1) initialize the workspace on USS, in particular by transferring the files contained in application-properties folder, 2) that IBM Z Open Editor has access to all the copybooks required by the program to be able to find them and transfer them to USS. This assumes that the COBOL Language Server is active because it is responsable to detect calls to copybooks, 3) that the userBuild trigered action pull all the copybooks identified to the workspace on USS, (userBuild is responsible to copy them to PDS during scanning / searching phase) 4) that the PDS containing copybooks not found by IBM Z Open Editor, or not accessible to IBM Z Open Editor, (this may concern product copybooks or cross-functional application copybooks constituting a framework), are accessible by the Cobol.grovvy script, at through either explicit coding of a SYSLIB at the compiler level, or a declaration in a Cobol.properties.

To find the copybooks, IBM Z Open Editor also uses a zapp.yaml file which identifies the different access paths to the copybooks, either locally or remotely on z/OS.

Perhaps this can help: Starting a user build. See information about Discover the dependencies to load for building.

[M-DLB]

What could be missing on IDz is a local property group: https://www.ibm.com/docs/en/developer-for-zos/16.0?topic=zos-creating-local-property-group-user-build This tells where to locate the dependencies when running a User Build. Is that something you already configured?

[mhardin18]

@M-DLB Thank you. This was indeed the problem. In my case it wasn't that it was not defined, but that it had an errant path element in it.

[mhardin18]

Thanks

[M-DLB]

Great to see the problem is fixed! I hope you don't mind if we close the issue then :)