OpenMake Meister

Dataset Names and Build Rules

z/OS Build Types and Rules are handled the same way Build Types and Rules are handled for any other supported operating system.  The biggest difference between z/OS and other supported operating systems is the structure and naming of files.  In addition, z/OS Build Types do not use Option Groups. 

Unlike development tools on other operating systems such as UNIX or Windows, the common mainframe development tools, namely COBOL, PL1, and Assembler, do not necessarily have standard input type and output type names.  It is common practice for each mainframe administrator to name their source and load libraries as they see appropriate.  There are some naming standards; however it is not unusual to see deviations from this standard.   For example, source module names could be:

ACME.PAYROLL.PROD.SOURCE(members)

 or

ACME.PAYROLL.PROD.COBOBL(members)

In the above example, both libraries contain COBOL programs.  In the first library name, the Type qualifier “SOURCE” does not indicate what kind of source code can be found in the library. It could be a mixture of PL1 and COBOL source code.  The product would not be able to execute against this library because it uses the Type qualifier, in this case “SOURCE”, to determine the Build Rule to execute and which compiler to call.  The OOMLBLDM program would not be able to determine from the “SOURCE” Type qualifier to call a COBOL compile or a PL1 compile.

For this reason, the Type qualifier and the organization of source code is very important.  In the second library name where "COBOL" is the Type qualifier, The OOMLBLDM program would immediately understand that the members in this library are COBOL programs and could execute the Build Rules.

In summary, dataset names are used to determine the file "Type" when interpreting the Build Rules.  For this reason, the method used for naming your source and load datasets is critical in order to build your components correctly.  It is also important that Datasets are used to store the same source code Types and that the source code Types are not mixed as in the "SOURCE" example above where both COBOL and PL1 modules were managed in a single Dataset.

Standard dataset names use multiple high-level qualifiers based on:

•  Project

•  Group

•  Type

The last qualifier of the dataset name is assumed to be the “Type” qualifier and is used to determine the "File Extension" on the Build Rule.

For example:

The Rule for a z/OS COBOL Load module looks like:

Dependency File Extension: .COBOL()

Target File Extension:  .LOAD()

.COBOL()  -> .LOAD()

<Project>.<Group>.COBOL(member) is compiled into

<Project>.<Group>.LOAD(member)

ACME.ACCTPAY.COBOL(acctpay1)  is compiled into

ACME.ACCTPAY.LOAD(acctpay1)

The Dependency File Extension “.COBOL()” tells the OOMLOM program that when building a z/OS COBOL load module use the dependency source code member of  the type COBOL to create a load module of the type LOAD.