Richard,

     I was able to perform Query Session, in fact there were numerous daily
admin processes going on (reclamation, migration, copypool work, etc.) - I had
no problem executing anything at the command line.  The NT session was in a
'receive wait' state and had a tape mounted on a device (since 18:00 the night
before), yet when I performed a query f=d on the volume, it said it was empty.
I contacted the client and asked if he could somehow terminate the session on
his end, he could not.  The AIX client (actually an SQL-Backtrack session) was
reported in 'Run' status, yet when I contacted this client he claimed there was
no active session displayed on his end.

     Nothing peculiar about either of the clients.  I believe the NT is at some
level of version 2 of the client, but the AIX is at version 3. I saw nothing to
indicate a hardware error in the server log, but I'll check syslog just to be
sure.  What exactly do you mean about using 'opsys' utilities if it happens in
the future - to identify the offending thread?

                    Thanks,

                    Ginny



Date:    Thu, 26 Aug 1999 13:54:02 -0400
From:    Richard Sims <rbs AT BU DOT EDU>
Subject: Re: ADSM OS/390 Server 3.1.2.20

>Anyone had a problem with level 3.1.2.20 with 'hung' client sessions sitting
out
>there for hours not doing any work, and the server sucking up cpu like there's
>no tomorrow?  I was forced to recycle my server this morning after numerous
>complaints from users and MVS performance folks; turns out ADSM was using 2
full
>cp's out of 4 on one of our production systems.  There were 2 client backup
>sessions that looked as though they were running from about 18:00 last night,
>but from the client end were not active (NT and AIX).
>
>Thanks for any info ....
>
>                         Ginny

Ginny - Were you able to get any Query Session info?  One wonders if the
        clients were hitting the client in some way, or whether they were
sitting there in IdleWait or some odd state.  Anything peculiar about the
clients (as in Win95 yesterday, WinNT or LINUX today)?  Or maybe a combination
of v2 and v3 clients, or some other peculiar circumstances that could be
determined from the event?  Any hardware errors?  Something odd triggered the
server to go bananas.  Could recur.  If so, try to use opsys facilities to
identify the process or thread so as to isolate the resource involved (each
process or thread tends to be dedicated).
   Richard Sims, BU