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:
|
