RTC Dependency build for MVS
2 answers
Hi Jim,
One of the artifacts produced by dependency build is a buildableFiles.xml file. It is generated on the server and contains all of the programs we've determined we need to rebuild, and all of their dependencies. It also lists why we need to rebuild (the program changed, one of its dependencies changed, etc). It is transferred to the build machine, where we then actually build the programs. You could access this information to perform your custom build. However, you need to be very careful here, and whether you can be successful depends on a number of factors. Can you tell us more about your full flow? What will your custom build consist of? Are you planning to also use RTC promotion, packaging, and deployment? Have you looked at the possibility of embedding your commands in the RTC translators?
A couple considerations we know you'll need right up front... We need to keep our build maps up to date in order to calculate the buildableFiles.xml. You could accomplish this by letting our build run, but not having it actually build anything. You'd want your build to run first, so that if you have a failure you DON'T let ours run. There is an undocumented property available that lets you skip the MVS exec, called teamz.build.ant.skipMvsExec. As it is undocumented it comes without promise/guarantees, but it is available in the posted drivers of the upcoming release, although it has been renamed to team.enterprise.build.ant.skipMvsExec. The build map lists outputs according to the DD defined as output in the translator, so you'd have to be careful about your build building what is declared in the buildmap.
Also, if you have any indirect dependencies, you're going to miss out on our handling of these in the dependency build. E.g., if you have a cobol program that depends on a copybook that is generated by a bms map, we will not be able to detect the dependency between the cobol program and the bms map if you're not actually running the our dependency build.
Should you choose to continue down this custom path rather than taking full advantage of our dependency build, you'll want to test out all of your various scenarios and flows to be sure you're achieving your desired behavior.
One of the artifacts produced by dependency build is a buildableFiles.xml file. It is generated on the server and contains all of the programs we've determined we need to rebuild, and all of their dependencies. It also lists why we need to rebuild (the program changed, one of its dependencies changed, etc). It is transferred to the build machine, where we then actually build the programs. You could access this information to perform your custom build. However, you need to be very careful here, and whether you can be successful depends on a number of factors. Can you tell us more about your full flow? What will your custom build consist of? Are you planning to also use RTC promotion, packaging, and deployment? Have you looked at the possibility of embedding your commands in the RTC translators?
A couple considerations we know you'll need right up front... We need to keep our build maps up to date in order to calculate the buildableFiles.xml. You could accomplish this by letting our build run, but not having it actually build anything. You'd want your build to run first, so that if you have a failure you DON'T let ours run. There is an undocumented property available that lets you skip the MVS exec, called teamz.build.ant.skipMvsExec. As it is undocumented it comes without promise/guarantees, but it is available in the posted drivers of the upcoming release, although it has been renamed to team.enterprise.build.ant.skipMvsExec. The build map lists outputs according to the DD defined as output in the translator, so you'd have to be careful about your build building what is declared in the buildmap.
Also, if you have any indirect dependencies, you're going to miss out on our handling of these in the dependency build. E.g., if you have a cobol program that depends on a copybook that is generated by a bms map, we will not be able to detect the dependency between the cobol program and the bms map if you're not actually running the our dependency build.
Should you choose to continue down this custom path rather than taking full advantage of our dependency build, you'll want to test out all of your various scenarios and flows to be sure you're achieving your desired behavior.
When a dependency build is requested, is it possible to access the list of modified and dependent files to accomplish an alternative build scenario?