Richard, You are correct. I suspected this 'hangng session' was from an earlier 'export node' I was working the day before. The export process did not complete. It failed abruptly. I cancelled the process so many times but no response. I will submit a PMR and ask the IBM guys to see how I can resolve this. Thanks again for your insight.
Avy Wong Business Continuity Administrator Mohegan Sun 1 Mohegan Sun Blvd Uncasville, CT 06382 (860) 862-8164 cell (860) 961-6976 Richard Sims <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> 04/19/2007 08:07 PM Please respond to "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> To ADSM-L@VM.MARIST.EDU cc Subject Re: [ADSM-L] Memory IPC On Apr 19, 2007, at 5:33 PM, Avy Wong wrote: > Hello, > I have this hanging session that has been going for over 35 > hr. I > tried to cancel sess 11171 many times but did not make it go away. > Any > idea? ... Avy - Your Query Session output ended up jumbled in the posting. Cleaned up, I believe it looks like the following: Sess Comm. Sess Wait Bytes Number Method State Time Sent ------- ------ ------ ------ ------- 11,171 Memory SendW 35.7 H 5.6 M Bytes Sess Platform Client Name Recvd Type ------- ----- -------- ------------------- 276 Admin Server WONGAV IPC In general, when you can't cancel a process or session, it is because an I/O operation is pending, and the communications path is still deemed to be viable. The least disruptive means of resolving that is to shake whatever it is on the other end that is not responding. We're lacking very important information here: what the session was about. This type of session is very unusual, and undocumented in the manuals, sadly. (It is not simple Shared Memory, as can be perceived by the Comm. Method being "Memory" rather than "ShMem", and Platform being "Server" rather than an operating system name.) I believe it is the special Inter-Process Communication type of session which is initiated when a server-to-server Export or like operation is initiated. In a case like this, you need to do Select * From Sessions to get the session start time, and then delve into your Activity Log to see what was done at that time, interacting with what other peer. Then you can ponder action. Performing Query PRocess may reveal an allied task on the local system; and you should also see what's going on at the peer end, which is where action is needed. (It might be hung on a media mount, at that end.) From your OS environment, you can also perform 'lsof' or similar on your dsmserv process to see what it's connecting to. The situation you are dealing with may be that described in APAR IC48311. Not knowing your TSM level, I can't fully assess that. You may need to confer with TSM Support, or proceed to apply the most current, standard maintenance for your version/release. Richard Sims ************************************************************************************************** The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copy of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. **************************************************************************************************