Obtaining ISPF foreground dumps from ChangeMan ZMF


Another customer issue that pops up from time to time is the inability to obtain a dump from the CMN ZMF ISPF client.  The actual abends can be unexpected or deliberate and related to issues within the product, environment or customizations.  

So, how can we get something more useful out of ZMF than messages such as “Abend 0C4000 hex occurred processing command 'CMNINIT '.”?   

The slightly unusual thing about this issue is that since the ability to capture a dump in this situation was significantly simplified in ZMF 6.1.0, the default setting in our sample code has been to always enable the dump capture processing.  However, for a variety of reasons, it appears that some customers may have missed or deliberately disabled this default.  So, let’s take an example and work through it.

In our example, whenever a user attempts to edit any package component:


The request always results in the following failure:

So, what does this tell us?  To be honest, just about nothing!  All we know is that somewhere within the ZMF ISPF session, a System 0C1 abend has been encountered.  This could be in Serena code, customer-written code, IBM code or just about anywhere.  

To extract some useful information that will help in diagnosing the problem we need to look at the ZMF ISPF session invocation routine.  That is, your ZMF connection rexx exec or CLIST routine.  The sample we supply is member CMN in the distributed CMNZMF.CLIST library.  And the lines relevant for our purposes here follow: 

PROC 0 SS() CON() DUMP(YES) TEST                                            
  /*   DUMP:  YES=Enable dump if an abend occurs.                    */     

This is reasonably self-explanatory, but by passing a DUMP(YES) parameter to the CMNINIT invocation ZMF will enable a special, dump-capture utility.  If we now logon using the rexx exec or CLIST with DUMP(YES) and repeat the edit request detailed above we receive the following failure:


And if we look in the user’s TSU session output, assuming that we have allocated a suitable dump file (e.g. SYSUDUMP or SYSABEND), we will see the full dump for the problem:


Now, as a ZMF user who is also responsible for supporting ZMF and who is disillusioned with the abends that I have encountered attempting to edit components within the ISPF interface, I switch to ZMF4ECL to look at my CMNEX036 listing and the cause of the S0C1 abend becomes clear:


So, I can see that removing the deliberate S0C1 abend (the DC F’0’ instruction) from my CMNEX036 code, rebuilding and re-deploying it will resolve the issue.

You may have noticed that the DUMP parameter was not the only one highlighted above.  The TEST option is important here, too. This is because the new dump capture technology was introduced in ZMF 6.1 to replace the old, more complicated ‘CMNIDIAG’ processing that existed in prior versions of ZMF.  However, the old CMNIDIAG functionality remains in place for other, internal development reasons.  

If an abend occurs whilst the TEST(T) option is activated, CMNIDIAG takes precedence over the newer dump capture processing introduced with ZMF 6.1.  When this occurs, and if the user’s SYSEXEC concatenation does not include the somnode.CMNZMF.REX library which contains the CMNIDIAG routine, then the user will receive the following error messages and neither mechanism will capture a dump:

IRX0406E REXX exec load file SYSEXEC does not contain exec member CMNIDIAG. 

IRX0110I The REXX exec cannot be interpreted.                               

IRX0112I The REXX exec cannot be loaded.                                    


To address this, the SYSEXEC allocation in the TSO User’s logon procedure JCL must include or be reallocated to include the rexx exec library that contains the distributed CMNIDIAG procedure.  For example:


    FREE F(SYSEXEC)                                                 

    ALLOC F(SYSEXEC) DA('CMNSUP.INTL.CMN810.REX') SHR                                                                                   




Pointing to an ALTLIB is NOT sufficient in this situation and great care must be taken when resetting the SYSEXEC allocation on exit. It may actually be simpler to logoff/re-logon to ISPF to ensure that reallocating the SYSEXEC file does not upset other ISPF applications that are executing within the user’s environment.   

In reality, the simplest solution is to set DUMP(YES) and to never enable the TEST option (i.e. do NOT set TEST(T)) when attempting to capture a ChangeMan ZMF ISPF interface foreground dump.  However, if for some reason you must run a user session to capture a dump with the TEST option enabled, and you have allocated SYSEXEC to include somnode.CMNZMF.REX, then the ISPF dialog at time of abend will look a little different to that explained above.  The user will instead be presented with the following screens at time of abend:


Pressing PF3 at this point will present the user with the following options:


Assuming that we do want to capture a dump, select the ‘Exit with Dump’ option, and the user will see the symptom dump information:


Again, the dump will be written to the active TSO user’s output dump file and will this time be accompanied by a SERPRINT file generated by the TEST option setting.

That hopefully covers more than you will ever need to know on how to capture foreground dumps from within the CMN ZMF ISPF client.  However, if not, or if you have any questions, then never hesitate to contact Serena Support who will be happy to help.


How To-Best Practice
Comment List