How can I control the SYSLIB entries for a z/OS dependency build? one maclib is missing, and one duplicated
How can I control the SYSLIB entries for a z/OS dependency build? one maclib is missing, and one duplicated.
The BASE maclib is specified in the translator for SYSLIB, but the log for the build shows two copies of the REL maclib, and no copy of the BASE maclib. The BASE maclib is not in the buildableFiles.xml or the macrodefs.xml, but does appear in the buildComponents.xml.
We are using RTC 5.0.2 and RDz 9.0.1.2.
The BASE maclib is specified in the translator for SYSLIB, but the log for the build shows two copies of the REL maclib, and no copy of the BASE maclib. The BASE maclib is not in the buildableFiles.xml or the macrodefs.xml, but does appear in the buildComponents.xml.
We are using RTC 5.0.2 and RDz 9.0.1.2.
2 answers
Janet,
Here's my understanding of this:
buildableFiles.xml contains source members under source control that marked as needing to be rebuilt based on the dependency analysis that was performed.
macrodefs.xml is an ant macro file which is effectively a translation of the language definitions and translators into ant syntax. Since language definitions and translators are directives on how to build source members there should be no list of members to be built in this file.
buildComponents.xml lists which system definitions (e.g. language definitions, translators, data set definitions) were included in the build.
Since the SYSLIB is a DD concatenation within a translator, I would expect to see what its value is in macrodefs.xml as a parameter in an <antz:concat dd="SYSLIB"... /> element. I would not expect to see it in buildComponents.xml unless you created a system definition with SYSLIB as the name.