Skip to main content
Status: Delivered

Changes have been made to deliver this requirement and the changed code will be seen in ZMF 8.3 patch1.

REXX exit users will not need to change anything, the REXX longMsg variable will now allow for up to 512 bytes of usable data (you can put as much as you like into longMsg but only the first 512 bytes will be used).

LE exit users will have to, at minimum, recompile their exits to pick up changed copybooks supplied with ZMF 8.3 patch1.

If LE users have no need of messages longer than 128 bytes they can continue to use the existing xxxxLONG fixed length fields. If they need more room then they must put a blank in the xxxxLONG field and then proceed to use the new xxxxXLON varchar fields which will accept up to 512 bytes of data.

Note: all HLLX functional areas have been addressed. 

I'm in the process of finally getting the remaining ISPF panel customizations converted over to use HLLX.  The "shortMsg" variable is 25 character in length, which matches the length of an ISPF short message.  However, the "longMsg" variable is limited to 128 bytes, whereas an ISPF long message is 512 bytes.  It would seem appropriate that the "longMsg" maximum length matches the ISPF long message maximum length.

With the ISPF panel customizations, I have taken advantage of being able to be verbose with the ISPF long messages to explain in detail to the ChangeMan ZMF user what the problem is, and possible solutions.  The bottom line is if the ISPF long message can help the ChangeMan ZMF user, and it saves the ChangeMan ZMF user from having to contact someone else to help him/her, then it ends-up being a time-saver all around, and results in better productivity because it enables the ChangeMan ZMF product to better communicate with its users while using it.

I have found that with the 128 character limitation of "longMsg" may not always convey the necessary information to the user as clearly as a longer 512 "longMsg" field would.

It would also seem appropriate that 


#ISPF
#panels
#HLLX
#messages
#REXX
Status: Delivered

Changes have been made to deliver this requirement and the changed code will be seen in ZMF 8.3 patch1.

REXX exit users will not need to change anything, the REXX longMsg variable will now allow for up to 512 bytes of usable data (you can put as much as you like into longMsg but only the first 512 bytes will be used).

LE exit users will have to, at minimum, recompile their exits to pick up changed copybooks supplied with ZMF 8.3 patch1.

If LE users have no need of messages longer than 128 bytes they can continue to use the existing xxxxLONG fixed length fields. If they need more room then they must put a blank in the xxxxLONG field and then proceed to use the new xxxxXLON varchar fields which will accept up to 512 bytes of data.

Note: all HLLX functional areas have been addressed. 

I'm in the process of finally getting the remaining ISPF panel customizations converted over to use HLLX.  The "shortMsg" variable is 25 character in length, which matches the length of an ISPF short message.  However, the "longMsg" variable is limited to 128 bytes, whereas an ISPF long message is 512 bytes.  It would seem appropriate that the "longMsg" maximum length matches the ISPF long message maximum length.

With the ISPF panel customizations, I have taken advantage of being able to be verbose with the ISPF long messages to explain in detail to the ChangeMan ZMF user what the problem is, and possible solutions.  The bottom line is if the ISPF long message can help the ChangeMan ZMF user, and it saves the ChangeMan ZMF user from having to contact someone else to help him/her, then it ends-up being a time-saver all around, and results in better productivity because it enables the ChangeMan ZMF product to better communicate with its users while using it.

I have found that with the 128 character limitation of "longMsg" may not always convey the necessary information to the user as clearly as a longer 512 "longMsg" field would.

It would also seem appropriate that 


#ISPF
#panels
#HLLX
#messages
#REXX

I can see how there would be a high-level of effort to make this change happen within ChangeMan ZMF, and why this effort would be declined at this time.  However, I would hope that this particular enhancement will be kept in the long-term radar.  For example, there may be times when a long component name needs to be communicated back to the user via a long ISPF message, and a 128-character limit for a long message along with a long component name can--and eventually will--result in truncation of the long message.

I was just doing some coding within CMNEX025 to stop the freeze process from happening, based on user option values.  I see that CMNEX025 supports a 512-byte long message that can very easily contain a 256-character component name.  Unfortunately, this would not be the case with HLLX exits, should special processing need to be done and a long component name needed to be communicated back to the user.

Status: Delivered

Changes have been made to deliver this requirement and the changed code will be seen in ZMF 8.3 patch1.

REXX exit users will not need to change anything, the REXX longMsg variable will now allow for up to 512 bytes of usable data (you can put as much as you like into longMsg but only the first 512 bytes will be used).

LE exit users will have to, at minimum, recompile their exits to pick up changed copybooks supplied with ZMF 8.3 patch1.

If LE users have no need of messages longer than 128 bytes they can continue to use the existing xxxxLONG fixed length fields. If they need more room then they must put a blank in the xxxxLONG field and then proceed to use the new xxxxXLON varchar fields which will accept up to 512 bytes of data.

Note: all HLLX functional areas have been addressed. 

I'm in the process of finally getting the remaining ISPF panel customizations converted over to use HLLX.  The "shortMsg" variable is 25 character in length, which matches the length of an ISPF short message.  However, the "longMsg" variable is limited to 128 bytes, whereas an ISPF long message is 512 bytes.  It would seem appropriate that the "longMsg" maximum length matches the ISPF long message maximum length.

With the ISPF panel customizations, I have taken advantage of being able to be verbose with the ISPF long messages to explain in detail to the ChangeMan ZMF user what the problem is, and possible solutions.  The bottom line is if the ISPF long message can help the ChangeMan ZMF user, and it saves the ChangeMan ZMF user from having to contact someone else to help him/her, then it ends-up being a time-saver all around, and results in better productivity because it enables the ChangeMan ZMF product to better communicate with its users while using it.

I have found that with the 128 character limitation of "longMsg" may not always convey the necessary information to the user as clearly as a longer 512 "longMsg" field would.

It would also seem appropriate that 


#ISPF
#panels
#HLLX
#messages
#REXX

Thanks, Steve, for the update that the long ISPF message will be 512 bytes in the Approval HLLX Interface in 8.3 patch 1.  As far as a priority list of HLLX functional areas, I would suggest rolling-out these changes to the Build HLLX Interface and then the Package Create/Update HLLX Interface.  Between build processes and package user variables (metadata), these are the areas that tend to have the most user-facing customizations.  Unless other clients have any other input, from our perspective, all the other HLLX functional areas could be updated in whatever order makes the most sense from R&D's perspective.

-- Ron

Terms & ConditionsAccessibility statement