Path: utzoo!attcan!uunet!husc6!mailrus!ames!pasteur!ucbvax!LBL.GOV!WHEELER%CC.UTAH.EDU%KL.SRI.COM%lbl%sfsu1.hepnet
From: WHEELER%CC.UTAH.EDU%KL.SRI.COM%lbl%sfsu1.hepnet@LBL.GOV
Newsgroups: comp.os.vms
Subject: What resources does an idle process tie up ... or why have
Message-ID: <880527105945.23e033d6@LBL.Gov>
Date: 27 May 88 17:59:45 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 42

Received: from KL.SRI.COM by LBL.Gov with INTERNET ;
          Thu, 26 May 88 19:51:02 PDT
Received: from CC.UTAH.EDU by KL.SRI.COM with TCP; Tue 24 May 88 23:52:10-PDT
Date: Wed, 25 May 88 00:51 MDT
From: WHEELER@CC.UTAH.EDU
Subject: What resources does an idle process tie up ... or why have
To: info-vax@KL.SRI.COM
X-VMS-To: in%"info-vax@kl.sri.com"
 
Posting-Version: unknown; site unknown
Subject: What resources does an idle process tie up ... or why have
 
Here are a few reasons that I know of for having an idle process killer.
(Please note, none of the system's I'm in charge of use an idle process
killer)
 
1) User's don't log out, someone use's thier account (student's in University
   environment)
 
2) You really want the user's list to reflect who is actually working on
   the system.
 
3) You install new software and the user who never logs out doesn't get
   the new DCL table starts complaining. (Hassle factor)
 
4) You re-install the DCL tables (after installing any layered product)
   and all the user's who haven't logged out are still mapped to the old
   installed DCL table and hence you use up some global pages. (I once
   didn't have enough global pages to continue the installation and hence
   had a machine that one couldn't log into! STOP/ID cured that problem)
 
By the way, does anyone *really* make all the user's log off and shutdown
the network to install new products?
 
Bob Wheeler
bob%howard@cc.utah.edu