Mark,
?
Does the lack of a "heartbeat" help or hinder? I don't know. I have kept my two KVMs up and running for 8 days, and sessions dialed to/through each XNET, and it doesn't drop.
?
What I did discover, is if one VM system goes down, planned or otherwise, you can not reestablish the XNET connections without re-IPLing the XNET on the surviving machine.
?
I tried to use the V cuu ACT/INACT to reestablish the connections, but that didn't work. Is it supposed to?
Having a heartbeat really wouldn't help matters much for detecting that a system on the other side has gone away.? The main problem is really the nature of CTCE devices on Hercules.? When one side goes down and Hercules is stopped and restarted, the state of the CTCE device is lost.? XNET on the side that remained up doesn't understand the state of the CTC as it sees it; it thinks it was left the way it was last used.? Understand that if this were a real CTC device on real S/370 hardware back in the day, this would be basically channel cables between two separate CPUs and a small bit of controller hardware logic.? If one CPU crashes, the state of the CTC remains unchanged.? What Hercules/CTCE does when it goes down is essentially the same as disconnecting the channel cables from the real CTC and powering down the CTC control logic, and restarting/reconnecting later.? The original state of the device was lost.? That does not typically happen with real CTCs; they were physically connected 24/7.
?
If you know that you are going to shut down one side deliberately, you should issue a V cuu,INACT on the side that will be remaining active.? Then shut down the intended system.? Once the shut down system is restarted and XNET is started, you should be able to issue V cuu,ACT on the side that stayed up.? None of this helps for an unplanned shutdown however.
?
I suppose a new command is needed to force reinitialization of the CTC and the connection for these situations, because V? INACT/ACT won't work in such cases.
?
Regarding your other suggestions:
?
0. Don't clear the stack, but read it, so when you IPL XNET you could stack D NODES and D TASKS to show up in your spooled console?
XNET doesn't run under CMS; it takes over the virtual machine and runs natively immediately after launching.? How about instead if the XNET CONFIG file allowed commands to be placed there that would be executed upon start up?? Note that there wouldn't be much shown or revealed by these commands if the CTCs are not yet connected and no one has yet DIALed to XNET.
?
?
1. SMSG capability, so I could SMSG D NODES and get the response back.
2. A restart capability, via SMSG? to reconnect systems when a failure happens.
Interesting ideas; I hadn't thought about the SMSG feature.? I'll look into these solutions for winter projects.
?
Regards,
Bob
?
?
