Skip to main content
Status: Delivered

This change (i.e. the introduction of the APRV0003 exit) has been completed and will be delivered with ZMF 8.3 patch 1 

We have come across a requirement where certain information needs to be communicated to the package approver for verification/consideration before they give a package approval. In our case, the approve/reject HLLX program will automatically determine when this information needs to be presented to the package approver via the "longMsg" variable.  However, the challenge is that there is no APRV0003 (pre approver entity list) HLLX exit point associated with the CMNAPPLS ISPF panel; there is only an APRV0103 (post approver entity list) HLLX exit point.  Though it is possible to communicate this information to the package approver via APRV0103, the information ends-up being communicated to the package approver after a package's approval-related action is done.  (Granted, some tricky coding can be done with the help of CMNVPOOL to display the necessary information before the actual approval action is accepted by the HLLX program, but this results in convoluted HLLX code and also results in an unrefined ChangeMan ZMF user experience because the user would have to do an approval action, then see the message, and then have to redo the approval action to continue.)

If an APRV0003 (pre approver entity list) HLLX exit point was available within ChangeMan ZMF, then the HLLX program can determine whether any message(s) need to be given to the package approver ahead of any approval action. It would be a much "smoother" user experience for the package approver to enter the CMNAPPLS screen, and immediately see any information that they need to take into consideration before giving the package approval.

Additionally, to circle back to Idea ID 2771140, will it be reconsidered to extend the "longMsg" variable to 512 bytes instead of 128 sometime in the future?  For our requirements that would ideally use APRV0003, we are bumping against this "longMsg" limit to the point that the long messages are getting too terse for the ChangeMan ZMF user to comprehend.  Since customization of ISPF panels needs to be avoided to allow to have a "common experience" between the ISPF client, Eclipse IDE client, etc., a longer message would handle long component names (up to 256 bytes), give the opportunity to provide a user proper/comprehensive communication (vs. hardcoding certain information in ISPF panels), etc.


#HLLX
#PackageApproval
Status: Delivered

This change (i.e. the introduction of the APRV0003 exit) has been completed and will be delivered with ZMF 8.3 patch 1 

We have come across a requirement where certain information needs to be communicated to the package approver for verification/consideration before they give a package approval. In our case, the approve/reject HLLX program will automatically determine when this information needs to be presented to the package approver via the "longMsg" variable.  However, the challenge is that there is no APRV0003 (pre approver entity list) HLLX exit point associated with the CMNAPPLS ISPF panel; there is only an APRV0103 (post approver entity list) HLLX exit point.  Though it is possible to communicate this information to the package approver via APRV0103, the information ends-up being communicated to the package approver after a package's approval-related action is done.  (Granted, some tricky coding can be done with the help of CMNVPOOL to display the necessary information before the actual approval action is accepted by the HLLX program, but this results in convoluted HLLX code and also results in an unrefined ChangeMan ZMF user experience because the user would have to do an approval action, then see the message, and then have to redo the approval action to continue.)

If an APRV0003 (pre approver entity list) HLLX exit point was available within ChangeMan ZMF, then the HLLX program can determine whether any message(s) need to be given to the package approver ahead of any approval action. It would be a much "smoother" user experience for the package approver to enter the CMNAPPLS screen, and immediately see any information that they need to take into consideration before giving the package approval.

Additionally, to circle back to Idea ID 2771140, will it be reconsidered to extend the "longMsg" variable to 512 bytes instead of 128 sometime in the future?  For our requirements that would ideally use APRV0003, we are bumping against this "longMsg" limit to the point that the long messages are getting too terse for the ChangeMan ZMF user to comprehend.  Since customization of ISPF panels needs to be avoided to allow to have a "common experience" between the ISPF client, Eclipse IDE client, etc., a longer message would handle long component names (up to 256 bytes), give the opportunity to provide a user proper/comprehensive communication (vs. hardcoding certain information in ISPF panels), etc.


#HLLX
#PackageApproval
Hi Steve,
 
Thanks for your prompt response.
 
As far as the restrictions outlined with APRV0003, where there would be no ability to alter the contents of the approval list, that would definitely not be a problem.  The main thing is to be able to use/read the contents of the various variables that would be available to APRV0003, and from there have the ability to better tailor/communicate with the approver, based on the current approval level is being processed.
 
To get a better idea of the “use case” for APRV0003, let me first give a little bit of background.  Within our organization, a requirement came-up to be able to categorize changes in a package associated with a given ChangeMan ZMF application.  To that end, we had introduced a concept of a “sub-application” that is stored in the Package User Variables.  Some ChangeMan ZMF applications—and I’ll be generic—such as the ABCD application can have a sub-application of EFGH, IJKL, or MNOP.  During package creation or package update, one could specify the sub-application here:
 
CMNDPUP1       UPDATE - ChangeMan ZMF Package User Information                
Command ===>                                                                  
                                                                   More:     +
         Package: ABCD000002      Status: FRZ      Install date: 20240723     
                                                                              
Supplemental Package Information                                            + 
  Sub-Application Mnemonic  . . . . . . . . .  IJKL      ( EFGH IJKL MNOP     )
                                                                              
Package Behavior Settings                                                     
  Enter "/" to select option                                                  
                                                             
  _ Promote with CICS NEWCOPY for Target Promotion Environment
  _ Demote  with CICS NEWCOPY for Target Demotion  Environment
...
 
One of the things that had come-up was that we wanted a supervisory-level approver to validate that the correct sub-application was selected.  It just isn’t realistic to think that an approver will take the time—or even remember—to go into the CMNDPUP1 panel to check to make sure that the sub-application was correct before doing the approval.  Thus, as part of the approval process, if APRV0003 was available the supervisory-level approver would get a message such as the following as they enter the CMNAPPLS panel, and before any approval-related action is taken against the ZMF package:

CMNAPPLS                         Approval List                 Row 1 to 3 of 3
Command ===>                                                  Scroll ===> PAGE
                                                                              
         Package: ABCD000002      Status: FRZ      Install date: 20240723     
                                                                              
  Approver Description                           User                         
                                                 Date     Time  Seq Status    
  Programmer                                     STD50                    
                                                 20231019 1340  00  Approve
  PROD SA or Application Manager                                               
                                                                90            
  PROD ST Deploy Management Install                                           
                                                                96             
******************************* Bottom of data ********************************
                                                                              
  HXAPPREJ-SUBAPPL-401-I  Ensure sub-application "IJKL" is correct for package.
  If required, use option 1.2.E or "UE" to change.                            
                                                                              
This particular message would only be given to the supervisory-level approver (level 90), since they are in a better position to know/validate the categorization of changes within the ZMF package.  Since the sub-application is presented to the approver before the package approval is done, then approver has an opportunity to make any corrections to the sub-application (per the instructions in the long message).  Once that is done, then the level 90 package approval would proceed.
 
Currently, since APRV0003 is not available, we are using APRV0103.  This means that the above message isn’t presented to the supervisory-level approver as soon as they enter the CMNAPPLS screen.  Rather, they can only get that message after they have given the approval action, such as the following:
 
CMNAPPLS                         Approval List                 Row 1 to 3 of 3
Command ===>                                                  Scroll ===> PAGE
                                                                              
         Package: ABCD000002      Status: FRZ      Install date: 20240723     
                                                                              
  Approver Description                           User                         
                                                 Date     Time  Seq Status    
  Programmer                                     STD50                    
                                                 20231019 1340  00  Approve
  PROD SA or Application Manager                 STD50                    
                                                 20231019 1345  90  Approve
  PROD ST Deploy Management Install                                           
                                                                96             
******************************* Bottom of data ********************************
                                                                              
  HXAPPREJ-SUBAPPL-401-I  Ensure sub-application "IJKL" is correct for package.
  If required, use option 1.2.E or "UE" to change.                            
 
The issue with this is that after the level 90 approver does the approval, then they will not be able to go back and change the sub-application to another value if it was incorrect.  As you know, either the level 96 approver would need to make that change, or the package would need to be reverted back to development status to make that change.
 
Please let me know if you need additional clarification on the use case I had described.
 
 
Thanks for reconsidering looking into the extending the longMsg variable to 512 bytes.  I can appreciate that it would a large undertaking.  In the above example, we are at about the 128-byte limit.  Granted, I could shorten the “HXAPPREJ-SUBAPPL-401-I” ‘message license plate’, make phrases terser, and use abbreviations.  But that would only get us so far, especially if we want wanted to communicate other package inconsistencies/concerns to the approver that need to be remediated.  As mentioned, we need to avoid hardcoding items/instructions in ISPF panels to allow to have a common experience between ISPF and Eclipse.  Longer “long messages” will at least give more flexibility to communicate what is needed to the user, and can be custom-tailored to each kind of approver (vs. putting a bunch of line items in an ISPF panel that may or may not be applicable to a given approver).  Would possibly first changing a single function in ZMF (such as builds) to have a 512-byte longMsg be a good approach to see how things fair before propagating this change across other ZMF functions?  (I suppose that doing this change against a low-impact ZMF function would be more desirable from your perspective.)  As implied, I would vote for the builds function due to long component name support, and it will be inevitable for us or another shop that will need it.  In our case, currently, here is an example of one long message that we use for Fidelity Information System applications:
 
FIS005 'INCONSIS ATTR AND LIBTYP'  .ALARM=YES                               
'FIS005 - In "&FISIUDSN" IU Source Control File (IUSCF), source ' +        
'"&CMPNAME" (section ID "&FISECTID") has a CUSTOM (column 65) or ' +       
'IN-HOUSE (column 66) attribute NOT set correctly relative to "&CMPNAME" ' +
'source''s "&CMPTYPE" library type.  To correct this, keep in mind: ' +    
'(1) for IN-HOUSE (SRC) source, set CUSTOM to " " and IN-HOUSE to "1", ' + 
'(2) for CUSTOM (XSR) source, set CUSTOM to "1" and IN-HOUSE to " ", ' +   
'(3) for VENDOR (VSR) source, set CUSTOM to "1" or " " and IN-HOUSE to " ".'
 
If it wasn’t for the above detailed message, I know that people would be asking a me and/or others what needs to be done.  Granted, even with this being documented somewhere, you are still taking the time searching the documentation, possibly tracking someone down to maybe even find the documentation, etc. compared to having all the information you need right when the issue happens.  (I would look at this as being analogous to pressing F1 from any ChangeMan ZMF screen to get the help that you need about the screen that you were in, as opposed to finding and opening-up a PDF documentation file, doing searches, and eventually finding the additional information that is required.)
 
In any case, thanks for your time in looking into this.  We really appreciate it.
Status: Delivered

This change (i.e. the introduction of the APRV0003 exit) has been completed and will be delivered with ZMF 8.3 patch 1 

We have come across a requirement where certain information needs to be communicated to the package approver for verification/consideration before they give a package approval. In our case, the approve/reject HLLX program will automatically determine when this information needs to be presented to the package approver via the "longMsg" variable.  However, the challenge is that there is no APRV0003 (pre approver entity list) HLLX exit point associated with the CMNAPPLS ISPF panel; there is only an APRV0103 (post approver entity list) HLLX exit point.  Though it is possible to communicate this information to the package approver via APRV0103, the information ends-up being communicated to the package approver after a package's approval-related action is done.  (Granted, some tricky coding can be done with the help of CMNVPOOL to display the necessary information before the actual approval action is accepted by the HLLX program, but this results in convoluted HLLX code and also results in an unrefined ChangeMan ZMF user experience because the user would have to do an approval action, then see the message, and then have to redo the approval action to continue.)

If an APRV0003 (pre approver entity list) HLLX exit point was available within ChangeMan ZMF, then the HLLX program can determine whether any message(s) need to be given to the package approver ahead of any approval action. It would be a much "smoother" user experience for the package approver to enter the CMNAPPLS screen, and immediately see any information that they need to take into consideration before giving the package approval.

Additionally, to circle back to Idea ID 2771140, will it be reconsidered to extend the "longMsg" variable to 512 bytes instead of 128 sometime in the future?  For our requirements that would ideally use APRV0003, we are bumping against this "longMsg" limit to the point that the long messages are getting too terse for the ChangeMan ZMF user to comprehend.  Since customization of ISPF panels needs to be avoided to allow to have a "common experience" between the ISPF client, Eclipse IDE client, etc., a longer message would handle long component names (up to 256 bytes), give the opportunity to provide a user proper/comprehensive communication (vs. hardcoding certain information in ISPF panels), etc.


#HLLX
#PackageApproval

Hi Ron,

I've just started looking at implementing this change, I have a couple of questions.

The existing APRV function data interface does not allow for an approver list to be sent to the exit, it has single instance fields for approver attributes. This is fine for the likes of the existing APRV0103 exit which is called once per approver processed (i.e. it is driven by actioning each line item from the CMNAPPLS panel). If called prior to displaying CMNAPPLS (i.e. for APRV0003) those single instance fields are set to the last approver in the table about to be displayed. Is this OK ?

If it's not, i.e. you need the list of approvers about to be displayed, then I will have to change the data interface to add a new variable set of fields specifically for this exit. 

Also, APRV0003 will be driven prior to each display of the CMNAPPLS panel. This means that it will be re-driven when the panel is re-displayed after all line items have been actioned, i.e. it will be driven on initial entry to the panel and then again after you've made one or more approvals (etc). I guess this is fine as you will probably want to put out the same longmsg each time the panel is displayed ?

All the best - Steve

Terms & ConditionsAccessibility statement