MPROUTE NOT RESPONDING TO COMMANDS FROM AUTHORIZED USER

 
 APAR Identifier ...... VM63778      Last Changed ........ 05/11/08
 MPROUTE NOT RESPONDING TO COMMANDS FROM AUTHORIZED USER
 
 Symptom ...... IN WAIT              Status ........... CLOSED  PER
 Severity ................... 3      Date Closed ......... 05/07/13
 Component .......... 568411220      Duplicate of ........
 Reported Release ......... 440      Fixed Release ............ 999
 Component Name VM LE                Special Notice
 Current Target Date ..              Flags
 SCP ...................
 Platform ............
 
 Status Detail: SHIPMENT - Packaged solution is available for
                           shipment.
 
 PE PTF List:
 
 PTF List:
 Release 440   : UM31470 available 05/07/20 (0503 )
 
 Parent APAR:
 Child APAR list:
 
 ERROR DESCRIPTION:
 The MPROUTE virtual machine unexpectedly hangs and does not
 respond to commands from any authorized user ID. A "DISPLAY PSW"
 CP command shows the MPROUTE virtual machine waiting on the CMS
 multitasking null thread.  Waiting on the null thread can imply
 that an unexpected loss of control has occurred.
 
 LOCAL FIX:
 
 PROBLEM SUMMARY:
 ****************************************************************
 * USERS AFFECTED: All users of LE's C runtime library,         *
 *                 especially z/VM TCP/IP's MPROUTE function    *
 ****************************************************************
 * PROBLEM DESCRIPTION:                                         *
 ****************************************************************
 * RECOMMENDATION: APPLY PTF                                    *
 ****************************************************************
 Problem occurred when an authorized user would issue commands to
 MPROUTE via the CP SEND command.
 
 The MPROUTE code is written in C and occasionally the C runtime
 would experience various program interrupts.  These programming
 interrupts are normally processed by the C runtime library and
 recovery from them is normally automatic.  In the case of this
 problem, the recovery path went through a CMS multitasking event
 handler.  During clean up in the event handler, the event
 monitor for the LE ABEND event was being deleted because it was
 defined as a one-time-only event.  The next program interrupt
 would "hang" in the CMS multitasking null thread because there
 was no event monitor registered to handle the exception.
 
 PROBLEM CONCLUSION:
 The fix for this problem is to change the creation of the event
 monitor for the CMS multitasking ABEND event handler for LE to
 be a persistent monitor instead of a one-time-only monitor.  To
 this end CEEHVEVC, the LE VM event create routine, has been
 changed to call the CMS multitasking EventCreate function with
 flags making the event monitor a persistent entity.
 
 TEMPORARY FIX:
 
 COMMENTS:
 
 MODULES/MACROS:   CEEHVEVC CEEPLPKA
 
 SRLS:      NONE
 
 RTN CODES:
 
 CIRCUMVENTION:
 
 MESSAGE TO SUBMITTER: