Figure 1 illustrates an NCPROUTE configuration using NCP as the destination hosts. In other configurations, destination hosts might not necessarily be NCPs.
Using Figure 1, assume that your NCP client ncp1 is channel-attached to an MVS™ host running an NCPROUTE server. The other two NCP clients, ncp2 and ncp3, are not running a RIP server. Also assume that permanent routes to ncp2 and ncp3 are not defined with the IPROUTE definitions in the NCP generation definition for ncp1. Your NCPROUTE server cannot learn a route to ncp3, because ncp2 is not running a RIP server. Your NCPROUTE server sends routing updates to ncp3 over the link to ncp2, but never receives a routing update from ncp2. After 180 seconds, your NCPROUTE server deletes the route to ncp2. This problem is inherent to the RIP protocol and cannot be prevented. Therefore, you need to add a passive route to ncp3 in the NCPROUTE gateways data set for the NCP client ncp1. This is the data set defined by the GATEWAYS_PDS statement in the NCPROUTE profile.
host ncp3 gateway ncp2 metric 2 passive
host 192.10.10.2 gateway 192.10.20.2 metric 2 passive
Similarly,
because ncp2 is not running an RIP server supported
by NCPROUTE, you need to add a directly-connected passive route
as follows: host ncp2 gateway ncp1 metric 1 passive
A
directly-connected passive route is one where the gateway address
or name is one of the local interfaces in the NCP generation.Assume that your NCP client is now ncp2 and is running an NCPROUTE server. ncp1 is also running a RIP server, but ncp3 is not. Your NCPROUTE server sends routing information updates to ncp3 over the link to ncp3 but never receives a routing update from ncp3. After 180 seconds, your NCPROUTE server deletes the route to ncp3.
You should add a passive route to ncp3 as follows:
host ncp3 gateway ncp2 metric 1 passive
host ncp3 gateway ncp2 metric 2 passive
or
host 192.10.10.2 gateway 192.10.20.2 metric 2 passive