Hello Folks,

Re: Hanging user session.

----------------------------------------------Willy Schriemer writes--
Hello HP3K experts, Yesterday we've had an hanging user session on one
of our machines. This session was consuming as much CPU it could get.
In Glance/XL we could see that the prio was 0 and the CPU always
greater than 95%. There was no locking situation on the databases.
The ABORTJOB didn't work. An ALTPROC said that the PIN coudn't be
altered.  In glance we saw that JSMAIN wat the only running program
for that session.  The session was connected with JINETD and
Reflection under Win/NT. The user killed Reflection with the
taskmanager.  At this point the looping user was created.

I've three questions for the HP3K list :
-1- Is there a way to abort a looping session.
-2- Could we prevent this problem with using DTC's and not JINETD.
-3- Is there a way to prevent a looping situation ?
----------------------------------------------------------------------

Hmmm....  To avoid confusion, I would suggest this session was not
hanging, but was "looping".  In the case of a system process "looping"
it is frequently the case that the process is in critical code and can
not be aborted and also is not servicing its port that instructs it
that an ABORTJOB has been performed and so it will not go-away...  In
this case the only solution is to get HP SUPPORT involved.  If it is
still possible to logon to the system (might need to use mgr.telesup
;pri=bs) then data can be collected by going into debug and taking
multiple stack traces of the looping process to determine where in the
code the process is looping through.


:hello me,mgr.telesup;hipri;pri=bs

:showproc ;pin=1;system;tree
...
D202  0:00.358  WAIT   J37           71   :RUN inetd.net.sys
B152  0:01.791  WAIT   J37             53   (INETD.NET.SYS)

:debug
HPDEBUG Intrinsic at: a.01086bf8 hxdebug+$e8
$114 ($33) nmdebug >
$114 ($33) nmdebug > pin #53
$115 ($35) nmdebug > tr,d,i
       PC=a.0024699c enable_int+$2c
NM* 0) SP=41844930 RP=a.0085c004
notify_dispatcher.block_current_process+$338
NM  1) SP=41844930 RP=a.0085de44 notify_dispatcher+$268
NM  2) SP=418448b0 RP=a.0028da64 wait_for_active_port+$e8
NM  3) SP=418447b0 RP=a.0028e6c8 receive_from_port+$544
NM  4) SP=41844730 RP=a.008337e4 selective_receive+$3f8
NM  5) SP=41844530 RP=a.007fa014 hpselect_nm+$254
NM  6) SP=418443f0 RP=a.007f9d8c ?hpselect_nm+$8
         export stub: a.0039a8c0 HPSELECT+$1054
NM  7) SP=41844070 RP=a.00399858 ?HPSELECT+$8
         export stub: 196.000139a0
NM  8) SP=41843af0 RP=196.00011b54
NM  9) SP=418438f0 RP=196.000187b8
NM  a) SP=41843630 RP=196.0000f2cc
NM  b) SP=418421b0 RP=196.00000000
     (end of NM stack)
$116 ($35) nmdebug > exit


After executing a bunch of tr,d,i we might see that different
procedure calls are being made and this will help HP SUPPORT a
bunch in the identification of a problem.

At this point it is important to CNTRL-B >TC and take a memory dump with
out altering this process in any way, with the goal that HP will be able
to identify the ROOT CAUSE of the problem and create a patch to fix it.

Answers to your questions:

I've three questions for the HP3K list :
-1- Is there a way to abort a looping session.
-2- Could we prevent this problem with using DTC's and not JINETD.
-3- Is there a way to prevent a looping situation ?

-1- In many cases if a process is not set critical or holding a resource
or locked waiting for a resource, an ABORTJOB will work.

-2- I assume from the text above that this possibly was a JSMAIN
associated with a Telnet Session.  I have not heard of a case (no SR's)
for a JSMAIN associated with a Telnet Session looping.  It may of been
possible to avoid this problem by using DTC's, but these also create a
JSMAIN...  It is really difficult to answer this question with out
further ROOT CAUSE analysis of the JSMAIN looping problem.

-3- We would need to collect further data to determine ROOT CAUSE of the
problem to determine if their was a method from a user perspective to
avoid this looping situation.

I hope this helps.

Regards,

James Hofmeister
Hewlett Packard
Worldwide Technology Network Expert Center
P.S. My Ideals are my own, not necessarily my employers.