Re: [ADSM-L] Memory IPC

2007-04-19 20:09:45
Subject: Re: [ADSM-L] Memory IPC
From: Richard Sims <rbs AT BU DOT EDU>
Date: Thu, 19 Apr 2007 20:07:47 -0400
On Apr 19, 2007, at 5:33 PM, Avy Wong wrote:

      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.
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

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