ADSM-L

Re: [ADSM-L] Memory IPC

2007-04-19 21:14:39
Subject: Re: [ADSM-L] Memory IPC
From: Avy Wong <AWong AT MOHEGANSUN DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 19 Apr 2007 20:58:50 -0400
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 <rbs AT BU DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
04/19/2007 08:07 PM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To
ADSM-L AT VM.MARIST DOT 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.
**************************************************************************************************

<Prev in Thread] Current Thread [Next in Thread>