Generate an ID that can be used to validate and track the software rollout

Thank you Karlhein Koch for the additional references! I submitted feedback to Mr. Ells as requested - just 1-1/2 years too late! I tried to copy you but I don't have a good email address for you, so instead I'll paste my reply here:

I know I'm 1 ½ years late based on RFE 102792, but I just submitted my RFE on Friday and learned about the other two RFEs this morning.

I agree with Mr/Ms Koch's requirement to use meta data stored with the module to determine the software level of a load module. My requirement (rfe #126135) is asking for the software level of a release stored in a similar fashion, but if we have to make it work by determining the level of each module, I would accept that.

SMPE could hold the manifest/composition of the modules via prereq, supercedes, and subreqs. All we would need is a single signature that we can tie back to SMPE. Then we can use a similar function in SMPE to prove the software level(s) associated with the signature.

Could the SMPE history be stored much like listings are stored for debugging purposes – they are stripped from the load module prior to loading so they don't consume virtual storage, but are available in the PDS if needed?

This almost sounds like a blockchain provenance problem? The signature/manifest would need to travel with the module/library as it is copied from library to library, and then be queryable from the system it is running in, so that we can certify the patching level of a system and/or load module.

The mainframe is now being held to higher stands to prove that the software we deliver remains untouched and is at the correct software level. When a vendor declares a “patch” (usually an RSU level for the mainframe, but could be an emergency PTF), we record proof of the patch and record our decision why the patch is or isn't being applied. If we decide to roll out the patch, we then record the rollout and patch level. Now we are being asked to show proof that the patch has been rolled out to each asset. An asset is an instance of the software, so for z/OS, it's an LPAR or STC. For subsystems like CICS/DB2, it is for each individual regions/members. Our upper management wants to be able to “click” on an asset and determine that the asset is compliant by showing its patch level. They want to do this for a server, a DASD device, and a mainframe asset. The solution doesn't need to include the interface that shows our topology – we can build that – we just need the raw data to feed it.

Here are three related RFEs with the same requirement.
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=126135
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=117083
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=102792

As I read through 117083, I feel the problem is being made bigger than it is. Please consider:
• Eyecatcher – we need an automated method to extract the level to be able to feed into our operational database, so an eyecatcher by itself is not an answer for us.
• Older Stabilized products – I plan to generate a hash that represents the module/library. We already do that via superc and pdsman. To represent a release, I plan to hash all of the hashes to come up with a release hash. If anyone adds a member or modifies any of the existing members, the hash won't match. We'll store the hash when the release is ready (just before rollout) and then compare it on regular intervals to validate it has been fully rolled out and that nothing has changed since the declaration of the release/patch. Could that hash be generated by an SMPE product and then stored with the module? It doesn't need to be an SMPE generated product to produce the hash – just a standard method that would tie back to an SMPE generated hash so that if it were in SMPE, it would match the SMPE hash. This would not require a reassembly (zap? Idr?) and would give us a way to find the signature. If there is no SMPE for the product (non-IBM, old, etc.), then we would just store the hash to make sure it doesn't change from the baseline.
• Numerous components – a single hash value computation for each module, stored with the module, then available for retrieval. Or, simply a function that can generate a single hash value for a library. The problem is still how to associate the library with the software instance, and I suspect each software would need to implement their own method?
• HIS already has a way to generate load module maps (MAPASID, MAPJOB) – could that be leveraged to generate a signature that could be tied back to a baseline signature?

Here are our basic requirements:
• Ability to prove that a module was not changed (e.g., spzap).
• Ability to reproduce the signature/hash and match to a stored baseline value.
• Ability to identify the PTF/Patch history.

There is no requirement that all of that be stored within the load module, however, if we take the approach that our debugging tools do, then the SMPE history can be stored as a “listing” with the load module. A vendor that doesn't use SMPE could use the same tool with their software levels to store the same type of data in the load module. We would still need a way to validate that the stored listing matches the load modules (i.e., someone zaps the load module but doesn't change the history associated with the module).

This is the URL to another RFE pointing into the same direction.
Maintenance information (eg. FMID and PTFID) are required meta data at a LMOD level to manage software lifecycle
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=117083

This somehow correlates with our RFE which was declined
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=102792
After longer discussions with John Eels including a patch level identifier at a meta data information at module or load module level we gave up to push this requirement.
At the end the idea using SMPE to provide and maintain this information looks to be the most practical approach. Also other vendor software would benefit from this functionality.
Publishing the used SMPE CSI with the related target libs is only suboptimal from our point of view.
We hope that SMPE Engineering is thinking about this need.

This somehow correlates with our RFE which was declined
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=102792
After longer discussions with John Eels including a patch level identifier at a meta data information at module or load module level we gave up to push this requirement.
At the end the idea using SMPE to provide and maintain this information looks to be the most practical approach. Also other vendor software would benefit from this functionality.
Publishing the used SMPE CSI with the related target libs is only suboptimal from our point of view.
We hope that SMPE Engineering is thinking about this need.