Here is my second failed attempt using what I think I learned from Brian.
>"First you need to (in vtam via V NET,INACT,ID=) inactivate any cross domain >and CDRSC connections between that LPAR and everyone else, then you need to >(in JES) using the >TSOCKET(name) command change it to connect=no. From that >point on, the physical connections just plain doesn't' exist and you can >remove it via the delete connection command that >someone mentioned earlier." I killed all SNA lines in my JES system. All nodes were inactive and not connected to me. I did $TNODE to set CONNECT=NO and to change the NAME=. --- I cannot fined a SOCKET to manipulate. I would have loved a delete node command, but still cannot find one. Restarting the SNA lines and foreign nodes reconnected the node number of the targeted node. One of my partner JES2 systems out there is acting as a guardian angel to preseve this link. even when I say connect=no and kill the physical links, it steps in to act as a middle man to preserve the connectivity. I define this angel with PATHMGR=YES. If I change that to NO he refuses to talk to me at all. =-=-=- It is beginning to look like I am just going to have to restart JES without any definitions with that node number Dynamic changes just do not work for me. If I do not define node(n2) on my system then the guardian angel will be stymied and I will have to live with the 'unknown node' messages when connectivity attempt is made by the guardian angel. Please do not tell the security auditors that I have no way to cut connectivity to an untrusted node. They will go ballistic. I guess that in a pinch I could fall back on the RACF defense (but would it catch the raw connectivity that my guardian angel is forwarding me from the badboy node?) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
