Labels

Add SA feature in CMN perspective mode
1
AlreadyInOctane
2
application relationships
2
Assemble
2
Baseline Ripple
1
Build
3
connection
1
correct edition
1
Customization options
7
Data Set Contention
1
Data Set Update Serialization
1
Dev and Prod staging
1
Display of userid who edit the component
1
E-mail
1
Event
2
Hash Token
1
HLLX
5
indicator
1
JCL Reformatting
1
Local and Remote System Information
2
Macro
1
more sort fields for staging
1
Multiple Assembles
1
Notification
3
Online Forms in CMN plugin
1
Reduce Customizations
3
REST-API services
3
Simplify
5
Source-to-Copybook
1
Source-to-Macro
1
Staging
2
Standards Enforcement
1
Syslib-exclude
1
Tutorial Reference
1
User Configurable
1
XML
1
ZMF
16
ZMF Plugin Activity Logs
2
ZMF Reports
2
ZMF4ECL
10
Idea ID: 2875443

Unique label ID for every version of a component

Johan Jacob
Status: Under Consideration

To enhance the source-to-load tracking mechanism to take into account SSV versions (and anything else we might consider useful) as an option (i.e. allowing the existing mechanisms to co-exist) is likely to be a sizeable undertaking. We will need to make sure the solution is generic.

The current development release is full so we will have to consider this further at a later date (i.e. for inclusion in a ZMF 8.3 patch release after patch 1).

CR 307002 has been opened to track this request and we will be in contact with Johan (the requester) to discuss the design as soon as time becomes available. 

See status update history

When enabling staging versions one can give a freeform text after each change of a component.

We have customised Changeman in such a way that this freeform text has a standard naming convention, using HLLX exits BULD00XC, BULD01XC, CKOT00XM and CKOT01XM. 

The label will look like 

nnn-FNC(APPLnnnnnn-vvv) opt. text

Where nnn is a sequence number incremented after each change

FNC : a functional ID : PKG = Checkout from package

                                     BAS = Checkout from baseline

                                     PRM = Checkout from a promotion dataset

                                     EDT = a version created after editing he component

APPLnnnnnn : the package from where was checked out

                        if checkout from baseline this will be the package that baselined the last changed version (not recompile)

vvv : the version of the component in that package

opt. tex : in case of a Baseline checkout (Base  nn)

               in case of a checkout from a promotion dataset : Lvl nn

At checkin or checkout time, these labels are also stored in a DB2 table

the version number is also added in the SETSSI, this is then handy when debugging a component in a test environment

I was wondering if people would like to see this feature as a standard part of ZMF ?

  • Hi Steve,

    Well that is whole lot to write down :-)

    - We have a lot of parallel development going on and testing can't always keep up and sometimes reported issues on a component pointed to a package were in the meantime the component was already fixed/upgraded

    - The SETSSI is stored in the loadmodule, but when in the meantime the component changed, the setssi is gone in ZMF and so we didn't knew on which version the bug was discovered. So additionally to the SETSSI, we store the version number into the load and then when a bug is reported, the developer can always trace back in which version it was discovered and how to fix in the code.

    - Also when people checkout from package (Release 1) to package (Release 2)  it might be that the R2 version is still in line with a proper sequential development path, but when R1 is baselined, the audit will give a SYNCH10, although this is false positive. We added a so called retrofit report to suppress them from the audit.

    - When we perform a recompile the recompile label references the last packageID-version of the last source change

    - Additionally we have created a csect that is imbedded in the loadmodule that lists all included copybooks (package version) and static routines, an internal fingerprint command extracts the csect and displays this detailed cross reference. So even at the load module level we know at any point in time how the loadmodule was build and with which versions of a any source

    I'm always happy to present this in a teams call

    Best regards

    Johan

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Cookies Preferences
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.