Hi :)
    Ok, I do remember seeing a similar thing with the library software we used
to run up at the university...

     The terminals were connecting via auto logon methodology (can't remember
how to do this)   when someone would turn off the terminal at the library the
session would hang the system :( ;(

Art Bahrs
+-------------------------------------------+------------------------------+
| Oregon Health Sciences Foundation         |The views here are no one's,  |
| Art Bahrs, Manager of Information Services|  least of all, mine!         |
| President, HP Oregon Regional Users Group (ORERUG)                       |
+-------------------------------------------+------------------------------+
| And the men who hold high places must be the ones to start.              |
+--------------------------------------------------------------------------+
| [log in to unmask] 'The Professor' Work: (503) 220-8333 Fax: (503) 228-9588 |
+--------------------------------------------------------------------------+


>>> Goetz Neumann <[log in to unmask]> 11/20/96 01:18pm >>>
Tjarko Dijkema wrote:
>
> We would like to invite anyone to help us solving a problem.
> Our environment: HP/3000-957SX running MPE/iX 5.0 with 120 users having a
> mix of HP terminals and PC's with Reflection for Windows (W3.1 and W95) as
> emulator.
> Comms hardware is DTC72MX.
> Only one application is running on the system being EMA/3000 (Materials
> management system developed by SIPM (Shell)).
>
> The problem: whenever a user accidentally switches off his PC or Terminal
> while in an active session with HP, that specific session will hang up and
> Glance shows a very high CPU usage causing a bottle neck condition wherein
> other sessions and batch jobs is starved for CPU.

From the above I assume all your users are connected per serial lines,
and not per NS/VT/LAN.

I would suggest you contact your local (BTW: what country does the
.qa domain stand for ?) support, to get you the latest Terminal IO
patch (DTSEDD9 as I recall) to rule out all solved issues from an
HP software perspective.

I recall to have seen 2 or 3 cases like this in the past, where the
faulty part was the application going into a tight loop and not the
operating system code looping (the fact that you are able to abort
the sessions supports that), though I do not want to do any finger-
pointing.

I do not know how your local HP support is organized (do you have
a Response Center and the associated contract ?), but if they fail
to debug the problem, they can get futher help from the expert
centers (kind of a worldwide response center for the response
center engineers).

Goetz.