You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I note that each language declares in its build-conf/<language>.properties file the characteristics of the PDS files that the build procedures will feed.
Our Applications are multi-language and therefore it is most often the same output PDS that are supplied, whether the source code is COBOL, Assembler, BMS or other.
For reasons of consistency (having the same language-independent definitions), it seems to me that it would be preferable for all the characteristics of the output PDS, but also perhaps the other PDS such as the PDS containing the sources and the copies / includes, ti be described globally in the same properties file, potentially the build-conf/build.properties file, or in a new build-conf/all.properties.
Languages would then just need to declare which PDS files they are going to use in their build-conf/<language>.properties file, but use declarations made in the global properties file.
If a language wants by exception to use its own PDS files, it can always declare them in its build-conf/<language>.properties file.
This problem appeared to us while wanting to implement our mechanism of impactBuild and fullPackage as described in #291 : we developed a script which rebuilds all the PDS of an Application starting from the contents of a tar file containing all the components; at this stage the notion of language does not exist and we need to recreate the output PDS independently of the languages, (in this case it is the extension or last level of qualifier of the PDS which determines its characteristics, and not the source code language).
Example of multiple declarations for the output PDS of loadmodules:
The text was updated successfully, but these errors were encountered:
Hi,
I note that each language declares in its
build-conf/<language>.properties
file the characteristics of the PDS files that the build procedures will feed.Our Applications are multi-language and therefore it is most often the same output PDS that are supplied, whether the source code is COBOL, Assembler, BMS or other.
For reasons of consistency (having the same language-independent definitions), it seems to me that it would be preferable for all the characteristics of the output PDS, but also perhaps the other PDS such as the PDS containing the sources and the copies / includes, ti be described globally in the same properties file, potentially the
build-conf/build.properties
file, or in a newbuild-conf/all.properties
.Languages would then just need to declare which PDS files they are going to use in their
build-conf/<language>.properties
file, but use declarations made in the global properties file.If a language wants by exception to use its own PDS files, it can always declare them in its
build-conf/<language>.properties
file.This problem appeared to us while wanting to implement our mechanism of impactBuild and fullPackage as described in #291 : we developed a script which rebuilds all the PDS of an Application starting from the contents of a tar file containing all the components; at this stage the notion of language does not exist and we need to recreate the output PDS independently of the languages, (in this case it is the extension or last level of qualifier of the PDS which determines its characteristics, and not the source code language).
Example of multiple declarations for the output PDS of loadmodules:
The text was updated successfully, but these errors were encountered: