Re: The JES2 NJE node that cannot die.
For those of you with any interest at all.The wicked witch (NJE node) is now dead to me The guardian angel keeping it on life support must have given up.Without any further actions on my part, it was suddenly gone. Wild theories exist: my guardian angel was discovered that I was gunning for this node. The standard PC problems fix of 'take two reboots and call me in the morning" might be involved. In either case, patience is a virtue. It turns out that JES2 takes suggestions, not commands. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: The JES2 NJE node that cannot die.
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
Re: The JES2 NJE node that cannot die.
I have already gone the VTAM Inact route but I have not tried it for EVERYONE. If I do temporarily kick everyone to the curb so that the dead node can be deleted, I have yet to find a JES command to delete a node. Best guess at this point, using your theory is to: Shut all JES2 connectivity that could potential lead me to the node to be removed. But If I had command to shut connectivity, my problem would be solved. $TNODE(BADBOY),NAME=GOAWAY No one will know who GOAWAY is and routing to anywhere should fail. Awkward, but potentially effective -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: The JES2 NJE node that cannot die.
Thanks, While that might shutdown the node, My eventual goal to is remove it entirely. I am trying to do it in stages. First, deactivate it. Wait. Then Remove it. I see no need to apply external solutions (RACF) to the procedure. My experience and monitoring tells me that this node is already completely unused. I am just trying to build a quickly reversable deactivation to cover myself just in case. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: The JES2 NJE node that cannot die.
Nice idea. The only CONNECT statements I have are for NJE over IP.I am not sure how to apply this to an SNA connection. I -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: The JES2 NJE node that cannot die.
There are several steps, 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. The point is that you disabled the ability for it to get anywhere else before you delete the connection. I'm not sure if you can change the connection to connect=no before VTAM or not, I never tried it in that order. If you want to leave the VTAM stuff active, you might be able to set the connect=no and then delete it, but I never tried. Normally I do these because I'm removing an LPAR and the VTAM connections are no longer needed. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: The JES2 NJE node that cannot die.
I think you need to set up your RACF NODES profiles and set the node in question to UNTRUSTED. Lennie Dymoke-Bradshaw https://rsclweb.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tom Longfellow Sent: 15 November 2023 15:46 To: IBM-MAIN@LISTSERV.UA.EDU Subject: The JES2 NJE node that cannot die. I have been in this business for decades and have run in to this situation on a few occaisions. Never really came up with the right recipe to make this happen. Our JES2 systems are NJE interconnected over SNA links interconnected with several other mainframes at other agencies. For resiliency and reliability they all act as store and forward nodes in the NJE network. We wish to no longer communicate with one of these nodes. Every method I use simply causes the NJE link to switch over to another mainframe in the interconnected network. $P $E $I commands at best cause failoever to another NJE node as the middle man. Killing the SNA CDRSC just causes failover as well. We have found nothing I can do to the NODE, LINE, or APPL that allow me to make this node dead to us. I am trying to do this gracefully by turning it off before modifying JES parms to remove it from my startup. Trying to preseve the possiblility of fallback in case some stealth user pops out from behind the woodshed. Any suggestions? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: The JES2 NJE node that cannot die.
Hi, You could try using RACF to prevent the node being used. >From the RACF Administrator's Guide: You can use profiles in the NODES class to control how RACF® validates inbound work on an NJE network. As with other RACF profiles, a NODES profile consists of a profile name, a profile class, a universal access authority, and an ADDMEM value. The profile name is a three-part identifier that indicates the origin of the work and the type of security information you want to validate. The universal access authority determines the actions that RACF performs on the inbound work. Best wishes Jack On Wed, 15 Nov 2023 at 15:46, Tom Longfellow < 03e29b607131-dmarc-requ...@listserv.ua.edu> wrote: > I have been in this business for decades and have run in to this situation > on a few occaisions. Never really came up with the right recipe to make > this happen. > > Our JES2 systems are NJE interconnected over SNA links interconnected with > several other mainframes at other agencies. For resiliency and > reliability they all act as store and forward nodes in the NJE network. > We wish to no longer communicate with one of these nodes. Every method I > use simply causes the NJE link to switch over to another mainframe in the > interconnected network. > $P $E $I commands at best cause failoever to another NJE node as the > middle man. Killing the SNA CDRSC just causes failover as well. > We have found nothing I can do to the NODE, LINE, or APPL that allow me to > make this node dead to us. > > I am trying to do this gracefully by turning it off before modifying JES > parms to remove it from my startup. Trying to preseve the possiblility of > fallback in case some stealth user pops out from behind the woodshed. > > Any suggestions? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: The JES2 NJE node that cannot die.
Have you looked at this webpage on deleting JES network connections - https://www.ibm.com/docs/en/zos/3.1.0?topic=section-del-connect-delete-network-connections Art Zeigler From: IBM Mainframe Discussion List on behalf of Tom Longfellow <03e29b607131-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, November 15, 2023 10:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: The JES2 NJE node that cannot die. I have been in this business for decades and have run in to this situation on a few occaisions. Never really came up with the right recipe to make this happen. Our JES2 systems are NJE interconnected over SNA links interconnected with several other mainframes at other agencies. For resiliency and reliability they all act as store and forward nodes in the NJE network. We wish to no longer communicate with one of these nodes. Every method I use simply causes the NJE link to switch over to another mainframe in the interconnected network. $P $E $I commands at best cause failoever to another NJE node as the middle man. Killing the SNA CDRSC just causes failover as well. We have found nothing I can do to the NODE, LINE, or APPL that allow me to make this node dead to us. I am trying to do this gracefully by turning it off before modifying JES parms to remove it from my startup. Trying to preseve the possiblility of fallback in case some stealth user pops out from behind the woodshed. Any suggestions? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
