Thank you for the background and the symptom descriptions. This is helpful in laying out what the problem can be here.
In my experience, the difference you are seeing between the Test environment working as expect and production not working as expected is due to which side starts the APPC sessions. In your test environment, does the VSE side start all the sessions you see routed on the one CSDCD? I think in production, the AS/400 may be starting sessions and for some reason the path is not taking the least weighted route.
When the CSDCD is acting as a gateway between LLC2 and Enterprise Extender, it does not flow directly from one adapter to another, or one protocol layer to another, like it would if the total path were both EE or LLC2. There is an inter-session route piece that it goes through to traverse the IP layer to LLC2 layer. It may be that when sessions go through a gateway like this, the AS/400 is not looking at the routed weights because the EE sessions (RTP pipe) will end on the CSDCD and gateway over the LLC2 session. I think you are setting the nn_rar correctly, but we may need to also look at another variable due to the gateway function.
In production, can you tell which sides are winners and losers (primary verses secondary) on the sessions taking the more weighted route? I think we will find that the AS/400 winner sessions are using this. I am not sure what parameter to use if this is the case to force it to use the other route.
Original Message:
Sent: Tue December 09, 2025 03:27 AM
From: Victor Hsiao
Subject: "route additional resistance" parameter requirement for change
Hi Jeff:
Background Information=======================
The end to end session is between a VSE CICS and AS400 APPC programs, and the CSDCD is the only node in the middle of the way. All three nodes are NN. CSDCDs runs as a VM.
In fact, I have another CSDCD with almost identical configuration with this one except the name. Those two CSDCDs serves as backup for each other and at this time the end-to-end sessions are distributed among the two CSDCDS.
The connection between VSE and this CSDCD is traditional LLC and no HPR/RTP function is used. The connection between AS/400 and this CSDCD is Enterprise Extender.
I made this adjustment(nn_rar) to make the end-to-end session to route to the other CSDCD node at normal time, but route back to this node at time when another CSDSD node is lost, based on client's requirement.
Symptom:===========================
I have also two CSDCDS, one VSE and one AS400 in the testing environment, I made the same type of change in one CSDCD, stop and start it (via sna stop without linux reboot) , and I see that the weight is changed via the command 'D NET,TOPO,LIST=NN; in VSE side, and I notice that session was going through only one CSDCD.
Then I adjust the production config in the same way, but scheduled a shutdown and boot of the Linux on last Saturday morning because it is the only time the end-to-end session will be disconnected as an daily operation. On this Monday I see the sessions are still distributed among two CSDCDS, and the 'D NET,TOPO,LIST=NN' command shows no change about the weight of the affected node. I am sure the Comm Server is recycled after checking the sna.err, and I see the CP-CP session between VSE and this CSDSD has disconnected for 1 hour and reconnected when the CSDCD boots to ready state. I am wondering if there is other parameters that affects the Topology update under this situation.
------------------------------
Victor Hsiao
Original Message:
Sent: Mon December 08, 2025 10:40 AM
From: Jeff Smith
Subject: "route additional resistance" parameter requirement for change
After changing the nn_rar value for the Comm. Server Linux node from 128 to 192, the change does not impact what route you see being calculated?
Have you forced a Path-Switch on the RTP sessions between the end points. This will cause which ever NN that currently has the CP-CP sessions with the end nodes to review its topology. Just rebooting a NN in the route will not change the current route setup since a new route had to be calculated when the Linux NN went offline and came back online. If another NN calculated a new route, it may not have had the new rar value at the time of the calculation. Forcing a Path Switch should cause a new re-calculation and a query for any new topology updates.
Jeff L Smith
------------------------------
Jeff Smith
Original Message:
Sent: Mon December 08, 2025 10:03 AM
From: Victor Hsiao
Subject: "route additional resistance" parameter requirement for change
Hello, All
I would like to change the "route additional resistance" of one NN node which lies between 2 APPN node (One is VSE and one is AS/400), so that this node is less preferred. After changing it and reboot the whole OS (Linux), the result of the query_node reflects the change, however, the result of query_nn_topology_node keep the original value before change. The session establishment result indicates that this node is still equally preferred with another node.
The same change was made under testing environment and the result is successful, however it fails on production environment. The change is about nn_rar value changing from 128 (default) to 192.
Any idea about the possible reasons? I am yet to start debugging.
------------------------------
Victor Hsiao
------------------------------