Use IDENTIFY to sign load modules

[dennis-behm]

This is enhancing the traceability capabilities between source code and the produced executables.

It leverages the IDENTIFY statement of the Binder/linkage-editor infrastructure to generate a string identifying the owning application and the state of the git repository, when the output was produced.

The binder is adding these information into the user data field of the load module, which can be retrieved with amblist.

          DATE         USER DATA
CSECT:    EPSCMORT
          06/19/2023   MortgageApplication/a21b6ab0

The feature is available for build files mapped to mapped to Assembler.groovy, Cobol.groovy and PLI.groovy. Because the signing it based on the git hash, it is only available for pipeline builds.

[dennis-behm]

@M-DLB, thanks for the review. I have incorporated your feedback.

@Crosswind, @M-DLB, Still one remaining item - the eye catcher. Instead of git-hash as the eye catcher - I would propose to use scmRef, while the git hash is just one part of the information. Thoughts?

[M-DLB]

@Crosswind, @M-DLB, Still one remaining item - the eye catcher. Instead of git-hash as the eye catcher - I would propose to use scmRef, while the git hash is just one part of the information. Thoughts?

Why not using comma-separated key-value pairs, like SCMRef:yyyyy,GitHash:xxxxx, where yyyyy is the Application name (or the owning Git repository) and xxxxx the Git hash?

[M-DLB]

Also, how do you deal with the 40-character limitation? (I believe you told me 40 was the limit) Would the record be truncated by the binder?

[Crosswind]

Also, how do you deal with the 40-character limitation? (I believe you told me 40 was the limit) Would the record be truncated by the binder?

@M-DLB This is handled in the code @dennis-behm wrote. It won’t return a value if it exceeds 40 characters.

@Crosswind, @M-DLB, Still one remaining item - the eye catcher. Instead of git-hash as the eye catcher - I would propose to use scmRef, while the git hash is just one part of the information. Thoughts?

Good question. I get the point but I feel like git-hash is most obvious and it’s definitely the main part of the information. I didn’t even think about including the repository name in the first place.

[dennis-behm]

The implementation today provides <application>/<abbrev.GitHash> as the identifier without an eye catcher.

Instead of the proposed scmRef, we could just SCM: as the prefix:

SCM:MortgageApplication/abcabcabc

@M-DLB, there is a warning message being issued into the log, and I assume that the LinkageEditor would write a warning as well.

Btw. the IDENTIFY option allows 80 chars for program objects! So we could debate if the warning should occur on 40 or 80 characters.

[M-DLB]

About the 40/80 bytes limitation: ideally, you should check if the target dataset is a PDS or a PDS-E so you know if the executable is load module or a program object. Depending on the check result, you may allow 40 chars or 80 chars. For a simple management, you can limit it 40 chars, but are we sure that it doesn't get to the limit easily?

If the short Git hash is 7 chars (could be up to 12 according to Git Doc), and with the 'SCM:' and '/' strings to split the information, it leaves 28 chars for the application name for load modules.

JZOS provides a way to check for the DSORG: https://www.ibm.com/docs/api/v1/content/SSYKE2_8.0.0/com.ibm.java.zsecurity.api.80.doc/com.ibm.jzos/com/ibm/jzos/ZFile.html#getDsorg--