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.