TCP/IP Server AMPX036I Assertion Failure When MPROUTE is
Initialized 01/08/21 PTF PECHANGE
APAR Identifier ...... PQ51304 Last Changed ........ 01/10/26 TCP/IP SERVER AMPX036I ASSERTION FAILURE WHEN MPROUTE IS INITIALIZED 01/08/21 PTF PECHANGE Symptom ...... IN INCORROUT Status ........... CLOSED PER Severity ................... 4 Date Closed ......... 01/08/23 Component .......... 5735FAL00 Duplicate of ........ Reported Release ......... 3A0 Fixed Release ............ 999 Component Name TCP/IP V2 FOR V Special Notice PE HIPER Current Target Date .. Flags SCP ................... FUNCTIONLOSS Platform ............ Status Detail: SHIPMENT - Packaged solution is available for shipment. PE PTF List: UQ54998 UQ54999 PTF List: Release 3A0 : UQ57205 available 01/09/13 (1000 ) Release 320 : UQ57206 available 01/09/13 (1000 ) Parent APAR: Child APAR list: ERROR DESCRIPTION: The TCP/IP server produces the following traceback when the MPROUTE server is initialized: AMPX036I ASSERTION FAILURE CHECKING ERROR TRACE BACK OF CALLED ROUTINES ROUTINE STMT AT ADDRESS IN MODULE DOMPRIOCTL 260 00CF17B2 TCIPDOW_IPDOWN DOIOCTL 55 00E19216 SOCKREQUEST PROCESSPENDMSG 194 00E1A80A SOCKREQUEST SOCKREQUEST 18 00E1B762 SOCKREQUEST SCHEDULER 146 00D5547E TCSCHED_SCHEDULER <MAIN-PROGRAM> 22 00CC4284 TCPIP VSPASCAL 00E47962 This traceback is produced on an inconsistent basis. LOCAL FIX: None. PROBLEM SUMMARY: **************************************************************** * USERS AFFECTED: z/VM TCP/IP LEVEL 320 and 3A0 USERS with * * PQ46571 applied * **************************************************************** * PROBLEM DESCRIPTION: With PQ46571 applied, receive * * AMPX036I Assertion failure on TCP/IP * * server when bringing up MPROUTE or * * ROUTED. * **************************************************************** * RECOMMENDATION: APPLY PTF * **************************************************************** When adding routes to the stack routing table, if a network route is not found, then the stack adds a SubnetInfoOnly route in addition to the regular route. The SubnetInfoOnly routes were added with the incorrect key. This results in assertion errors when new SubnetInfoOnly routes are added, because they already exist. PROBLEM CONCLUSION: The routine FillIpRoutingKey has been changed to always use a key of the NetAddress for SubnetInfoOnly routes. This will prevent the AMPX errors. In addition, in the areas that fill in the information for SubnetInfoOnly routes, the code was changed so that the SubnetMask for SubnetInfoOnly routes matches the SubnetMask for the regular route. TEMPORARY FIX: COMMENTS: MODULES/MACROS: MSTCP TCIPDOW TCPIP TCTREEP SRLS: NONE RTN CODES: CIRCUMVENTION: MESSAGE TO SUBMITTER: