Most large legacy projects have mixed teams, usually with some newer developers and a few developers with many years of experience. Mandating significant changes to their development practices can be disruptive to the team. If their source base currently contains files with extensions that reflect the source language, and they reside in the z/OS UNIX File System, then it’s a perfect fit for building with IBM DBB (IBMs Dependency Based Build tool), or z/OS UNIX “make”.
Otherwise, you (the DevOps engineer) may need to adapt to their existing development practices. For a “worst case” example, if all their source, of multiple languages, resides in a single “Source” PDS, and therefore contains few clues to indicate the language of each source member, you have a challenge. In this case, neither z/OS UNIX “make” nor DBB can easily provide a usable “dependency-based build” solution.
In my past experience, build JCL stored in a product build PDS may be used effectively to produce your distributed executables, but this approach does not allow the desired “dependency-based build”.
In this case you may need to update your existing build JCL to generate ADATA records. The Library records usually contain a complete record of all inclusions (Macro, or Copy members). You will need to obtain or write an ADATA analysis tool. From that and from the Binder control cards, you should be able to determine the build JCL to manually submit.
Would it be better to automate the product build? Obviously, yes. But to get there you need to convince the development team that moving the source to the z/OS UNIX file system is a better way to work. Convincing a large development team to change their legacy processes can be a challenge. Too much pressure can result in turnover and loss of expertise.
In the past, I have extracted and reported on ADATA Library records, Option records, and ESD records. It works, but it is a great deal of work to maintain, or you can convince the team to obtain, install, and configure “IBM DevOps Code ClearCase” which can do all of this.
In a modern z System environment, it is better to modernize your development and DevOps processes. It can be a herculean effort to convince a large team to participate in such a modernization effort, but over the long run it is worth it.
About H&W
