Conference noted::hackers_v1

    Look at BUSY - it protects your terminal from other people using
    your privileges, but still allows them to leave you messages. Also
    they can see where you are (if you say so in your 'message') and
    when you are due back. It also traps all broadcast messages and
    shows them to you when you get back.
    
    Very useful - ie I use it all the time.
    
    (As a bonus, if all your section/system/... use it then you can
    look at a community wide bullitin board to see where everyone is.
    not used this myself but sounds a good idea).
    
    Don.

Your System Manager (or someone with access to the proper macro file) can
also disable SPIRIT for your UIC.

-Andy


I had this same problem at one time.  Wrote a small basic file that displays
f$time (double height/width) and loops every 60 ticks.  Of course, this sorta
defeats the purpose of having SPIRIT to begin with but...

Send me mail.

	i use this
	
	jack 

$	on error then goto out
$	on control_y then goto out
$       write sys$output ""
$loop:
$	write sys$output "#5"	! All off, bottom left.
$	wait 0:10:0					! Wait 10 minutes
$	time	:=	"''f$time()'"
$	goto loop
$out:
$       write sys$output ""
$	show def

Use a command-procedure like this:
                        
      $ ASSIGN NL: SYS$OUTPUT
      $ LOOP:
      $        WAIT 00:00:20
      $        DIR SYS$SHARE
      $        GOTO LOOP
      $
      $ DEASSIGN SYS$OUTPUT

The "DIR SYS$SHARE" (or whatever) uses enough CPU time and/or does enough
I/Os to make SPIRIT think that you process is active.

Ron

   The following command procedure will lock your terminal, displaying
   the time every 2 minutes. When you want to get free type ^C and enter
   your password. Change this password to whatever you please.
------------
    
$ on control_y then goto exit
$ on sever_error then $ continue	! trap errors & ^Y's for security
$ bell[0,7] = 7
$clear
$ write sys$output "--------------------------"
$start:
$time
$wait 0:02:0
$goto start

$ exit:
$ set term /noecho
$ write sys$output "** Exit to user account **"		! escape to user account
$write sys$output " "
$ read sys$command pass /prom="Password: "
$ set nover
$ PASS=F$EDIT(PASS,"UPCASE")
$ set term /echo
$ if pass .eqs. "YOURPASS" then $goto done
$ write sys$output "?SERVER-W-Bad password, failure logged.",bell,bell
$ goto start
$ done:
$ clear
$ exit

    WHILE YOU ARE RUNNING THESE I CAN'T LOG ON BECAUSE THERE ARE TOO
    MANY USERS!
    
    SHARE THE RESOURCES PLEASE
    
    (FLAME OFF)

    A method I'm fond of, is a program that ALWAYS sleeps (rather than
    waking every two seconds), and ONLY wakes when it traps a broadcast
    message.  When it catches a broadcast message, it merely displays
    it.
    
    What I like about this method is that SPIRIT itself will cause you
    to stay logged on !  SPIRIT's own act of typing "You have not done
    anything for ten minutes" (or whatever it types) will cause that
    message itself to be trapped and displayed by the program, hence
    qualifying as "doing something".
    
    /Eric

    For you folks that like the command files that prompt you for a
    password, see note 113.42.
    
    I like it better than others because it doesn't require you
    to think of a password.  Instead, it prompts you for your REGULAR
    vms password.  Hence you needn't remember two passwords.
    
    /Eric

    re .7:
    
    	I will grant that on some overloaded systems, SPIRIT (et al)
    do have a useful function, but on systems where it's rare to have
    more than 10 or 15 users at a time (and _never_ any waiting), all
    it does it waste _my_ time logging back in....
    
    Willie
    

    re: .9
    
    but...but... can't you just USE one password???? 
    
    re: .7, .10
    
    you also could add that most any serious development programmer
    has a rather extensive environment set up (subprocesses, mongo logical
    name tables, symbol tables, etc) and it is much easier just to
    suspend an environment than to delete it and start all over again.
    
    also, locking up a terminal has it's advantages, especially when
    it's in your own office... 
    

Hi!	RE:  < Note 332.7 by BIGALO::STARIE_DICK "STARIE_DICK" >

I appreciate your frustration but suggest that you vent it on the
cause that leads to the use of spirit defeaters and not the people who
use them. I don't have the need to run a "DELAY.COM" or
"FOOL_SPIRIT.COM" these days. However, it used to be that (in an old
group) leaving your terminal for something like a work-related meeting
or conversation that exceeded the -- what are folks using for SPIRIT
intervals these days -- 15, 20, or 30 minute interval was a real pain.
I should have been able to come back to my resource and have it, but
SPIRIT logged me out.  I agree, however, that running a DELAY program
for an entire day is a bit much.

So, no flame or any other pummeling intended and hoping you'll look at
this from another point of view...

P.S. I have not forgotten that SPIRIT has security implications, too, 
and am not addressing those needs here.

Eric:  RE: .8

What about using BUSY?  That has the security and is nice to use.

CAEM/CIM Product Development | MLO5-2/E50 Pole 36A | 223-3590

    
    
    I know its not very secure, but the best way i have found for keeping
    spirit from logging me out.. is just to do a SPAWN...
     It saves just a few minutes when your by your terminal and some
    is talking to you for 40 mins...
    
     jka ( Spawn/Stay_away_spirit )
    

Besides a terminal and associated line, how much resources does an idle
terminal session use up?  Seems to me that SPIRIT would only be useful for
dialup lines and a system with "public" terminals that are usually in use.

-Mike

    Well, the reason I am given for SPIRIT is that it keeps people from
    leaving (at the end of the day) without logging out.  Sure, educating
    users (or having the night watchman change their passwords) would
    eliminate this, but then again, SPIRIT gives the system mangler
    a greater feeling of power over the lusers....  Since I have yet
    to forget to logout when I go home, and having a task dumped just
    because I didn't hit return every half hour is a royal pain, I asked
    about a simple exorcist.
    
    Willie
    

    In addition, the processes on some systems tend to be quite large
    (consider a tp system).  So, those users that don't log out use
    up memory, increase paging (as the working sets get trimmed), and
    possibly add some swapping.  Also, most of my systems run very close
    to the maximum number of users all the time.  I'd like to keep those
    that are not doing anything off so that those who are, can (or
    something like that!).

re:    < Note 332.15 by PHENIX::SMITH "William P.N. (Wookie::) Smith" >


>    Well, the reason I am given for SPIRIT is that it keeps people from
>    leaving (at the end of the day) without logging out.  Sure, educating
>    users (or having the night watchman change their passwords) would
>    eliminate this, but then again, SPIRIT gives the system mangler
>    a greater feeling of power over the lusers....  Since I have yet

    Sounds like the system manager should just run SPIRIT during the
    non-working hours if unattended terminals are his concern.

re: .0
    
    For me, I use phone access to our systems a lot. The terminal switch
    has a 10 minute data inactivity check after which it will drop
    the line. Sometimes I walk away for a break and get distracted for
    longer than ten minutes. If the switch drops the line, I have to
    dial back in, enter two passwords before I even get to enter my
    username. 
    
    To get around this problem, I start up EMACS with a timed checkpoint
    every 9 1/2 minutes. After 9 1/2 minutes EMACS will checkpoint
    my files and generate a message on my terminal which satisfies the
    switch's need for data activity. 
    
    Before you flame at me for holding onto a phone line :

    	I am careful not to use this workaround when I am going
    to be gone for an extended period of time, i.e. for more than 30
    minutes.

						Has3

    	The security arguments for something like SPIRIT are weak.
    1) Even a minute away from your terminal is plenty for a prepared
    hacker. To be effective SPIRIT should time out in approximately
    the time that it takes you to walk out of sight of your terminal.
    
    2) A terminal left logged in and found by a hacker is not inactive,
    so it misses the cases it really should be catching.
    
    3) SPIRIT cannot distinguish a secure, password locked, LAT session,
    and I suspect that it also does not distinguish a session on a
    disconnected virtual terminal. Also, a terminal that is inactive
    is not neccessarily unattended. The user may be on the phone or
    looking something up in a manual. SPIRIT can easily delete something
    for security reasons that was not insecure.
    
    
    	From a resources point of view, SPIRIT costs the resources it
    uses itself, the resources of any "ghostbusters" introduced into
    the system because of it, the resources required for a user to log
    in again and reset his process context after a SPIRIT deletion
    including his time wasted. In most cases I would expect that the
    cost of this is more than the cost of more memory, or the cost of
    retuning the system so that the occasional inactive process is
    outswapped. 
    
    
    	Finally, no version of SPIRIT can know the purpose of every
    possible process and the implications of deleting it. The first
    version of SPIRIT that I heard of would crash a system by deleting
    the disk ACP if noone had opened a file for a while. A later version
    would do the same by deleting the DBMS monitor process. In a known,
    stable environment it can no doubt be taught all the things it should
    leave alone, but I would not want to risk it on my machine.
    
    		Dave

    re: .-1
    
    That's exactly the reason we don't use it (generally) at our plant.
    In one case (our manufacturing systems), we just plain _can't_ run
    SPIRIT since users could be in the middle of transactions and they
    might just walk away, and if SPIRIT deleted their process then the
    database would be corrupted, since they were actually in the middle
    of a transaction. "Inactivity" generally translates to LEF wait,
    and SPIRIT isn't smart enough to know that the user is in an image,
    and the LEF wait is actually during a transaction.
    
    So we end up walking around the plant logging off user's terminals
    at the end of the day - of course, the user catches hell because
    we also report them... (hey, I didn't write the procedure, I just
    live with it)
    
    /pjh in the north country
    

    SPIRIT sounds likes it was devised for people to serve a computer,
    rather than the other way around.
   
    I need a computer to get my work done.   If I keep getting logged
    off, then the operations people running the machine are getting
    in the way of my work.   Does that sound very cost effective?
    
    If resources are indeed tight buy more equipment and then read what 
    Dave Monahan said a couple back.   
    
    <flame off>
    
    	KC

    SPIRIT and SPIRIT like programs are commonly known as FLUSH out
    here in the field (at least in our area).  There are a million and
    one different versions of them, and especially for 'guest' systems
    programmers, like us software specialists, they are a pain in the *ss.
    
    These things seem to be a hold over from the bad-old-days of small
    adress space (RSTS), and scarce terminal lines (1 DZ-11).  On these
    systems they made sense.  But, it has been over two years since
    I have seen one of these things doing more good than harm on a system.
    
    Reasons to use them:		responses
    
    	Security;                       SPIRIT is inadequate for this
    					 task.  (See earlier notes)
    	 - Users walk away from their
    	   terminals logged in.	     	- Educate them.
    					- Use BUSY type programs.
    					- Use locking on Terminal Servers.
    					- Buy terminal locks.
    	 - Users go home while still
    	   logged in.			- (See above)
    					- Run it only at these times.
    					- Get better site security.
    	
    	Performance;			SPIRIT will itself have many
    					detrimental side effects on
    					performance. Espicialy on large
    					systems.
    	 - CPU usage.
    					- Idle processes don't use CPU.
    					  SPIRIT, and SPIRIT beaters
    					  do.
    	 - Process slots.		- Raise MAXPROCNT (sp?), re-AUTOGEN
    					  and reboot.  Costs next to
    					  nothing.
    	 - Balance set slots.		- Raise BALSETCNT or encourage
    					  swapping. (Same as above).
    	 - Memory.			- Proper setting of SYSGEN
    					  parameters should cause idle
    					  processes to be trimmed down
    					  to almost nothing.
    	Management;			SPIRIT will cause more management
    					problems than it will solve.
    	 - Can't run Backup overnight
    	   with all these open files
    	   from idle processes.		- Yes you can. Use /Ignore=Interlock.
	 - Can't Backup these files
    	   with assurance if they
    	   aren't closed.		- Sometimes valid. Run SPIRIT
    					  or some more specific program
    					  only when you need it.
    	 - Limited number of dial-in
    	   lines.			- Usually valid.  Make sure
    					  SPIRIT only affects the processes
    					  that actually use the lines.
    
    I might add that I have actually heard every one of these vehemently
    argued by some knowledgable system manager or system programmer.
    They seem to be wide-spread beliefs that are continuously redistributed
    and reaffirmed.  (I would like to know by whom).
    
    Additionaly these disadvantages are rarely mentioned:
    
    	- They are easy to subvert.
    	- Users hate them, so they are always subverted.
    	- They rarely take all the proper precautions.
    	- They can have nasty side effects (see earlier notes).
    	- I personally believe that some real percentage of bugchecks
    	  and system hangs are due to them.  For instance:
    		-- They usually run at elevated priority.  Mistakes
    		   (ie. infinite loops) can be severe.
    		-- Some processes can be seen, but not deleted.  These
    		   programs will sometimes spend forever trying to delete
    		   a process like this.
    		-- They ALL use $DELPRC without using $FORCEX. An uninformed
    		   system manager running one of these on a VMS 4.4
    		   system with global files can watch his system lock
    		   up and die like clockwork about every hour or less.
    		   (v4.4 RMS global buffers have a bug).
    	- They NEVER catch all of the processes that they are supposed
    	  to.
    	- Many of the dumber ones don't take subprocesses into account.
    	  They see an idle parent and delete it.  Of course the active
    	  subprocess dies too.
    
    
    Easy ways to defeat them:
    
    	1.  If you have the authority, remove it.  If not, find someone
    	  who does and try to convince them.
    
    	2.  If you have the right, and its smart enough, put yourself
    	  on the list of users to be excluded.  Or try to talk someone
    	  who can into doing it for you.
    
    	3.  If you have sufficient privleges, write a program to set
    	  the DELPEN (delete pending) bit of the FLAGS field of your
    	  PCB.  This has the hilarious side effect of making you invisible
    	  to $GETJPI, $DELPRC, and just about all other system services.
    	  You'll show up on $SHOW SYSTEM, SHOW USER, and MONITOR PROCESS,
    	  but not on SHOW PROCESS/CONTINUOUS, or 99% of all user-written
    	  programs.  REMEMBER to turn this off before you log out!
    	  [NOTE: If you use CHMKRNL, you are on your own.  Do not blame
    	  me for side-effects.]
    
    	4.  If you can run BUSY, do so.
    
    	5.  If you can use MONITOR, do so.  This is particularily useful
    	  if you work on a terminal server and you are getting zapped
    	  while your sessions are switched.  Those 3 second AST-s keep
    	  coming in, even when your terminal is XOFF-ed.
    
    	6.  If its smart enough to deal with subprocesses, spawn one in
    	  your login.com.  This keeps most of them off your back forever.
    	  If its smart enough to kill idle subprocesses, AND the parent
    	  (has to be if it can handle All-in-1) then write a command
    	  procedure to write to the null device then wait for 5 minutes,
    	  then loop.  The increasing IO count always fools them.  Tell
    	  other users about this one, it only requires the tmpmbx privilege
    	  and a UAF subprocess quota above 1.  EVERYbody has that much.
    	  This means that instead of causing idle processes to be logged
    	  out, the SPIRIT program will be causing TWICE as many processes
    	  to be created.  The dramatic irony here is great.
    
    	7.  If you're lazy, just run some program that traps broadcast
    	  messages such as All-in-1(!), EVE, NOTES, LSE, etc... This
    	  usually works.
    
    If you should happen to be involved with one of these, then at least
    make sure that it does these things:
    
    	- Has a facility for specifying Users, and Programs to be excluded!
    
    	- Allows you to specify which terminal lines are to be affected
    	  or not affected.
    
    	- Has an easily adjustable timeout that can be set for different
    	  periods based on time-of-day, day-of-week, and username.
    
    	- Affects only interactive processes unless told otherwise.
    
    	- Always takes active subprocesses into account.
    
    	- ALWAYS uses $FORCEX first, followed by $DELPRC when deleting
    	  a process.  (VERY important).
    
    	- Always keeps a log of when it deleted a process, identifies
    	  the process, and the reason(s) why it was deleted.
    
    
    -- Barry
    

    Re .21:
    Fully agree. Another side effect of Spirit, back three years ago
    with scarse resources and a terminal switch:
    the proliferation of
     100 Goto 100
    Basic, Fortran or DCL command procedures. Of course, this also shows
    need for user education.
    
    John.

    BTW: The system in question has just had a change in policy regarding
    Spirit.  We now get 15 minutes idle time to the first warning, and
    a five minute 'grace' period till logout.  This is an 11/750 with
    maybe 20 users max, the reason for the policy change was given as
    insufficient resources....  Oh well, guess I can pass around the
    spirit killer.  Don't really need BUSY or something that locks up
    the terminal, there aren't any hackers running around _that_ building
    looking for logged in terminals to play with.  :+)
    
    Willie
    

When I was a system manager, way back in the old days.  I had the same problem
with Spirit.  I solved the problems by only running Spirit after hours (after
4:30 PM).  That kept the users from complaining and still logged out processes
that had been left lying around.

I have a different problem where I work.  It's the MICOM switch.  If it doesn't
see terminal INPUT (from the keyboard) it disconnects the line.  If I'm running
a long compile or other compute bound job sometimes they die when the terminal
line gets disconnected.  I have to keep typing ^T every 10 minutes in order
to survive.

When not running a program, I have a command file that loops and just does a
"SET TERM/INQUIRE" every 1 minute.  That at least hangs onto the line.

						/Skip

    Set your terminal answerback to ^T.  Then write a short program that will
    do a broadcast to sys$output of the request-answerback sequence
    every 'n' minutes.

    Start this program running in a subprocess /OUT=NLA0:/IN=NLA0:/NOWAIT.

	On a similar note, our management has just decided to try out
a program (like SPIRIT) called "chipmunk" (sp?)...
	Does anyone know what this is?  Is it better/smarter/worse
than your typical kill-idle-process watcher..?

				- Dan

    We've had some problems with chipmunk.  The command procedure that
    comes with it for starting it up runs it at priority 10.  At this
    priority, it would occassionally hang the system (hung in a loop?).
    
    Also, I've seen it exit for no explained reason.
    
    tom_p

<mild flame on>

I think you're all missing the point - its all very well for you lot in the
USA with Mips coming out of your ears, but *some* of us out here in the rest
of the world don't have your advantages.

Here in SE England we have 1 11/750 to serve as a Demo/OA/learning machine for
a user population of about 75. The machine dies with more than 15 users, and
without SPIRIT , most of us would sit doing nothing all day  - or get in at
07.30 to be sure of logging on..

All these complaints should really be aimed at the people who starve us of
compute power, not the poor old system managers who have to try to please
all of the people most of the time.

<flame off>

BTW - I find a set term/inquire + 100 (a = a+1)'s every 10 minutes works fine.

Dave K

    The next version of SECURPACK will contain a "spirit" like program.
    The program is called IPM (Idle Process Monitor). It has all the
    nice features and even does a $FORCEX before stopping the process.
    
    SECURPACK V3.0 is due for release in mid January.
    
    Ed

    	I think .28 is missing the point. You have 3 types of users
    on systems.
    
    1) Cooperative users. For these SPIRIT actually makes things worse
    because of the resources it uses itself.
    
    2) Careless or uncooperative users. For these the correct answer
    is to identify them and use pressure from their management to solve
    the problem. Previous comments show how it will always be possible
    for an uncooperative user to beat SPIRIT, and the fix is to ask
    his manager to ask him not to.
    
    3) Ignorant users. This should be solved by education and advice
    from the system manager. A user can be informed of the advantages
    both for himself and the system as a whole of correct usage. For
    these users SPIRIT is a poor and inadequate substitute for the system
    manager tuning the system and providing advice. It is likely to
    convert these users into category 2!
    
    
    	And I do understand the problem. For a while I was system manager
    of an 11/750 with 1.5Mb..  This had about 60 authorised users and
    about 20 typically logged in at a time. It was also the area router
    for area 51.

    
    We've abandonned our spirits and are attempting to control the
    situation through user involvement.  The following command file is
    submitted on every node from a system account in the following manner
    (the example uses node COMET): 
    
    $ SUBMIT/NOPRINT-
    /QUEUE=COMET_BATCH-
    /LOG=LEFT_LOGGED_IN_COMET.LOG-
    	LEFT_LOGGED_IN
    
    It sends VAX Mail to any non-OPERATOR, interactive process it finds
    logged in at 02:30 that has also been logged in for 8 1/2 hours or
    more.  It re-submits itself for the next day. 
    
    
$!
$!	left_logged_in.com
$!
$ set verify
$ node=f$getsyi("NODENAME")
$ time=f$cvtime(f$time(),,"TIME")
$ if time .ges. "02:30:00.00" then goto resubmit1
$ submit -
	/queue='node'_batch -
	/log=left_logged_in_'node'.log -
	/after="02:30:00.00" -
	/noprinter -
	left_logged_in
$ exit
$resubmit1:
$ if time .ges. "06:30:00.00" then goto resubmit2
$ submit -
	/queue='node'_batch -
	/log=left_logged_in_'node'.log -
	/after="TOMORROW+02:30:00.00" -
	/noprinter -
	left_logged_in
$ goto main_program
$resubmit2:
$ submit -
	/queue='node'_batch -
	/log=left_logged_in_'node'.log -
	/after="TOMORROW+02:30:00.00" -
	/noprinter -
	left_logged_in
$ exit
$main_program:
$ context=""
$loop:
$ on error then goto loop
$ pid=f$pid(context)
$ if pid .eqs. "" then goto wrap_up
$ un=f$getjpi(pid,"USERNAME")
$ if un .eqs. "OPERATOR    " then goto loop
$ mode=f$getjpi(pid,"MODE")
$ if mode .nes. "INTERACTIVE" then goto loop
$!
$!	check how long the process has been logged in
$!
$ date1 = "''f$cvtime(f$time())'"
$ date2 = "''f$cvtime(f$getjpi(pid,"LOGINTIM"))'"
$ year1 = f$integer(f$extract(0,4,date1))
$ year2 = f$integer(f$extract(0,4,date2))
$ month1 = f$integer(f$extract(5,2,date1))
$ month2 = f$integer(f$extract(5,2,date2))
$ day1 = f$integer(f$extract(8,2,date1))
$ day2 = f$integer(f$extract(8,2,date2))
$ hour1 = f$integer(f$extract(11,2,date1))
$ hour2 = f$integer(f$extract(11,2,date2))
$ minute1 = f$integer(f$extract(14,2,date1))
$ minute2 = f$integer(f$extract(14,2,date2))
$ second1 = f$integer(f$extract(17,2,date1))
$ second2 = f$integer(f$extract(17,2,date2))
$ centi1 = f$integer(f$extract(20,2,date1))
$ centi2 = f$integer(f$extract(20,2,date2))
$!
$ month = month1
$ day = day1
$ year = year1
$ return = "c1"
$ goto julian
$c1:
$ julian1 = julian
$!
$ month = month2
$ day = day2
$ year = year2
$ return = "c2"
$ goto julian
$c2:
$ julian2 = julian
$!
$ centisec1 = centi1+(100*(second1+60*(minute1+60*(hour1))))
$ centisec2 = centi2+(100*(second2+60*(minute2+60*(hour2))))
$!
$ centisec = 8640000*(julian1-julian2)+centisec1-centisec2
$!
$ goto continue
$julian:
$ m = month
$ d = day
$ y = year
$ if m .gt. 2 then goto l10
$ m = m + 9
$ y = y - 1
$ goto l20
$l10:
$ m = m - 3
$l20:
$ c = y/100
$ ya = y - 100*c
$ julian = 146097*c/4 + 1461*ya/4 + (153*m + 2)/5 + d + 1721119
$ goto 'return'
$continue:
$!
$ if centisec .lt. 3060000 then goto loop ! 8.5 hours = 8.5*60*60*100
$ term=f$getjpi(pid,"TERMINAL")
$ open/write lli left_logged_in_'node'.txt;0
$ write lli ""
$ write lli "This is just to remind you that your ",node," account was"
$ write lli "discovered logged in at ",f$time(),"."
$ write lli "If you were actually using your terminal at that time, please"
$ write lli "disregard this notice; however, if you were not, then you"
$ write lli "either failed to log out properly or someone else is using"
$ write lli "your account."
$ write lli ""
$ write lli "Information about the process:"
$ write lli "Login was: ",f$getjpi(pid,"LOGINTIM")
$ write lli "PID: ",pid
$ write lli "Terminal: ",term
$ write lli "Authorized privileges:"
$ auth=f$getjpi(pid,"AUTHPRIV")
$loop2:
$ len=f$length(auth)
$ if len .eq. 0 then goto jump2
$ loc=f$locate(",",auth)
$ priv=f$extract(0,loc,auth)
$ write lli "                       ",priv
$ auth=auth-priv-","
$ goto loop2
$jump2:
$ cpusecs=f$getjpi(pid,"CPUTIM")/100
$ write lli "CPU time used (seconds): ",cpusecs
$ write lli "Number of images run down: ",f$getjpi(pid,"IMAGECOUNT")
$ running=f$getjpi(pid,"IMAGNAME")
$ if running .eqs. "" then running="(DCL)"
$ write lli "Current image: ",running
$ write lli "Current state: ",f$getjpi(pid,"STATE")
$ close lli
$ mail/subject="Off-hour login" left_logged_in_'node'.txt 'un'
$ goto loop
$wrap_up:
$ delete/log left_logged_in_'node'.txt;*
$ exit

    Re. .28
    
    	I think .30 hits it right on the head.  I would like to reaffirm
    however, apart from any flaming, that ANY program that deletes
    processes for not using any CPU, can not magically deliver more
    free CPU.  This is true for 8800's down to 730's.  I have been a
    system manager, and system programmer for a vareity of operating
    systems & cpu's (8650's, 730's, 785's, 11/34's, 11/40's etc...)
    and I can tell you both from experience and from research that the
    only thing that these programs are good for is freeing up a limited
    non-dynamic resource like a telephone line.  If your 750 is short
    of CPU I can assure that it comes from too many people trying to
    use it, not from too many people logged-in but not using it.  The
    truth is that that 750 probably needs some tuning of its
    memory-mangement parameters.  This is the source of many imagined
    gains from SPIRIT-like programs.
    
    Re .29:
    	Well thank goodness for the $FORCEX's anyway!
    
    -- Barry

SPIRIT-like programs can also be used for security purposes -- the
idea being that you shouldn't leave an unattended terminal logged
in for extended periods of time.  With that consideration, is there
some way to do a DISCONNECT/CONTINUE for another process?

Re: .26 (my own) and .27  - Chipmunk

	I just found out that Chipmunk DOES NOT use $FORCEX, it simply does
a $DELPRC.  Can anyone be more descriptive on the RMS-global buffers problem
(or other problems) that $DELPRC can cause in VMS V4.4?

				- Dan

p.s.  Mgmnt has Chipmunk running on a 10 system cluster here.

    RE: .-1
    	The 4.4 global buffers problem will only show up IFF:
    		- You've got a file with global buffers,
    		- A process has access to the file on more than one
		  channel,
    		- Other than the first channel to access the file has
		  accessed it last,
    		- The process is then DELPRC'ed

    Fixed in 4.5 with a patch available for 4.4.

    Re .34
    
    	Norm explains the infamous rms global buffers problem very well
    in .35, and he is right, All-in-1 is the most likely enviornment
    for it.  In actual fact it is normally pretty rare, but on the cluster
    where I am a resident we have nearly 2000 all-in-1 subscribers and
    management insists on running a "flush" program constantly.  We
    saw it a lot, until all global buffers were turned off.  Wish they
    would have used $FORCEX instead.
    
    	I might add that the global buffers problem is only the most
    obvious of many reasons not to delete a process without forcing
    an image-exit first.  Also, I belive that you should not try to
    delete the process immediatly after the $FORCEX, but should wait
    for 5-20 seconds.
    
    Re .33:
    	I personally do not believe that SPIRIT type programs are adequate
    for the enforcement of ANY security needs, nor do I believe that
    they form a necessary part of any adequate security package.  In
    fact I regard them as quite dangerous in this matter, because like
    all halfway security measures they delude thier owners into beliveing
    that they are secure when they are not, and they encourage inquisitive
    users to attempt to break this apparent security because they appear
    to be (and in fact are) so easy to beat.
    
    	Sadly at this time you not only cannot disconnect another process,
    there does not even exist a library call to disconnect yourself.
    Hopefuly some enlightened, and talented developer will give us a
    way to do this real soon now (hint, hint).  I also think that the
    use of DISCONNECT over $DELPRC would be a quantum leap forwards
    for the viability of SPIRIT like programs.
    
    -- Barry
    

>    	Sadly at this time you not only cannot disconnect another process,
>    there does not even exist a library call to disconnect yourself.
>    Hopefuly some enlightened, and talented developer will give us a
>    way to do this real soon now (hint, hint).

How about:

$ SET TERM/MODEM <terminal name>
$ SET TERM/NOMODEM <terminal name>

Does that do a DISCONNECT or just a logout?

-Mike

    To effectively disconnect yourself....
    
    	$&<cr>
    
    try it!
    
    -John

> < Note 332.8 by REGINA::OSMAN >
> 
>     A method I'm fond of, is a program that [...] wakes when it traps a 
>     broadcast message.  When it catches a broadcast message, it merely 
>     displays it.
>
	I found by accident that VAXnotes has this feature!  I left
	VAXnotes running one night when I went home.  When I came in
	the next morning, VAXnotes was still there catching a broadcast
	from Spirit every two hours and displaying the "first warning"
	message.

				-John A. Wasser

    re:	every two hours
    
    Life is rough, PHENIX just upgraded to an 11/785, and due to the
    ensuing resource crunch (or something???), we now have Chipmunk. I'm
    not too sure, as there has been no official word (not even a notice
    saying Chipmunk was to go into effect), but it seems to give about 20
    minutes 'idle' time before throwing you off. 
    
    Question for you Vaxen gurus:  What's a reasonable load for an 11/785
    assuming most users aren't very busy? 
    
    Willie
    

    Also is it possible to set that rodent up so that it only wakes
    up when there are more than X number of users?  Also how does one
    find out how many and what kind of resources are taken up by Chipmunk?
    
    Willie
    

    Boy, I am not impressed by Chipmunk.
    
    VPA or SPM would tell you what resources Chipmunk uses. 
    
    BTW, we are having the same basic problem on our OA systems, which
    are 750's. They are basically overloaded. Mostly DECalc, MAIL (no
    DECmail tho) and SLIDE, GRAPH, and other supported products.
    
    The systems are    s l o w  ...
    
    However, someone here installed "MANAGE" on one of the worst systems.
    That's another spirit-like clone. We are running VPA on that system
    trying to find how bad it's mis-tuned. It turns out that MANAGE
    is eating 10% of the available CPU in any period during peak hours!
    (peak hours = 7:00 -> 17:00, avg users = about 30)
    
    figure it out...10% of a 750's meagre CPU tends to make that a pretty
    ludicrous gesture, running mis-"MANAGE"...
    
    
    /pjh

    Re: .36:
>       Sadly at this time you not only cannot disconnect another process,
>    there does not even exist a library call to disconnect yourself.
>    Hopefuly some enlightened, and talented developer will give us a
>    way to do this real soon now (hint, hint). 

    Not a developer, but maybe you'll settle for a hacker.
    Here's an example of how you do it, lifted from TECO-32 (which I
    lifted from DCL and modified)... enjoy!
    	-Rick
    
	.TITLE	DETACH - Disconnect terminal
	.IDENT	'V40.10'
 
;****************************************************************************
;*									    *
;*  COPYRIGHT (c) 1985 BY				    		    *
;*  DIGITAL EQUIPMENT CORPORATION, MAYNARD, MASSACHUSETTS.		    *
;*  ALL RIGHTS RESERVED.						    *
;* 									    *
;*  THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND COPIED   *
;*  ONLY IN  ACCORDANCE WITH  THE  TERMS  OF  SUCH  LICENSE  AND WITH THE   *
;*  INCLUSION OF THE ABOVE COPYRIGHT NOTICE. THIS SOFTWARE OR  ANY  OTHER   *
;*  COPIES THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO ANY   *
;*  OTHER PERSON.  NO TITLE TO AND OWNERSHIP OF  THE  SOFTWARE IS  HEREBY   *
;*  TRANSFERRED.							    *
;* 									    *
;*  THE INFORMATION IN THIS SOFTWARE IS  SUBJECT TO CHANGE WITHOUT NOTICE   *
;*  AND  SHOULD  NOT  BE  CONSTRUED AS  A COMMITMENT BY DIGITAL EQUIPMENT   *
;*  CORPORATION.							    *
;* 									    *
;*  DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE  OR  RELIABILITY OF ITS   *
;*  SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL.		    *
;* 									    *
;*									    *
;****************************************************************************
;
	$DEVDEF				; Define device characteristics
	$DVIDEF				; Define $GETDVI codes
	$IODEF				; Define $QIO codes
	$TT2DEF				; Define terminal characteristics
	.PSECT	TECO$IMPURE	RD, WRT, NOPIC, NOSHR, NOEXE, QUAD

DVI_ITEM:	.WORD	4			; Size of return
		.WORD	DVI$_DEVDEPEND2		; Want device dependent2
		.ADDRESS DEVDEP2		; Return here
		.LONG	0
		.WORD	4
		.WORD	DVI$_DEVCLASS		; Device class
		.ADDRESS CLASS			; Return here
		.LONG	0
		.LONG	0

DEVDEP2:	.BLKL	1			; Device dependent bits
CLASS:		.BLKL	1			; Device class
IOSB:		.BLKQ	1			; I/O Status block
 
	.PSECT	TECO$CODE	RD, NOWRT, PIC, SHR, EXE, QUAD, GBL, NOVEC
	.SBTTL	Disconnect process from terminal
;+
; TECO$DETACH - Disconnect process from terminal
;
; This routine is called to disconnect a virtual terminal.
; It is called when the Detach bit [et bit 32] is set.
; INPUTS:
;	Channel for terminal, only argument.
; OUTPUTS:
;	Return status.
;-
	.ENTRY	TECO$DETACH, ^M<> 
;
; Check that terminal is disconnectable.
;
	BSBW	CHECK_DISC			; Check disconnectability
;
; Disconnect the terminal.
;
10$:	$QIOW_S	CHAN=4(AP),-			; Execute the QIO
		IOSB=IOSB,-
		EFN=#1,-
		FUNC=#IO$_SETMODE!IO$M_TT_DISCON; Disconnect setmode
	BLBC	R0,30$				; Branch if error
	MOVZWL	IOSB,R0				; Use IOSB status
30$:	RET					; Return

	.SBTTL	Check that terminal is disconnectable
;+
; CHECK_DISC - Check that terminal is disconnectable
;
; This routine is called to check that the terminal is disconnectable.
;
; INPUTS:
;	Channel to terminal device to be disconnected
;
; OUTPUTS:
;
;	Routine only returns to caller if terminal is disconnectable.
;-
CHECK_DISC:					; Check disconnectability
	$GETDVIW_S  CHAN=4(AP),-		; Get the terminal chars
		ITMLST=DVI_ITEM,-		; Item list
		IOSB=IOSB,-			; I/O Status block
		EFN=#1				; Random EFN
	BLBC	R0,90$				; Branch if error
	MOVZWL	IOSB,R0				; Use IOSB status
	BLBC	R0,90$				; Branch if error
	CLRL	R0				; Assume not disconnectable
	CMPL	CLASS, #DC$_TERM		; Is it a terminal?
	BNEQ	90$				; Nope. Can't do.
	BBC	#TT2$V_DISCONNECT,-
		DEVDEP2,90$			; Branch if not disconnectable
	MOVL	#1, R0				; Return OK status
	RSB
90$:	RET					; Return if can't do it.

	.END

    This is a kernel mode hack to disconnect a terminal which doesn't
    belong to you.  **** I haven't tested it yet. Volunteers? ***
    I probably should put in more checks but ...

    matt

;    How to do a disconnect of someone else's terminal:
;    
;    You can't do a IO$_SETMODE!IO$M_TT_DISCON because the setmode will
;    be blocked by the pending read.  I think the "simplest" of doing
;    that is to $CMKNRL and find the UCB of the terminal, then abuse
;    the TT port/class driver interface by issuing a CLASS_DISCONNECT
;    to the class driver at device IPL.
;
CLASS_DISCONNECT = 24;

	.ENTRY	TT_DISCONNECT, ^M<R5>
	IFRD	SIZ=#4, ADR=(AP), DEST=110$	; readable arguments?
100$:	MOVZWL	#SS$_ACCVIO, R0			; nope, show error
	RET					; ...and return
110$:	TSTB	(AP)				; else how many do we have?
	BNEQ	120$				; more than 0?
	MOVZWL	#SS$_INSFARG, R0		; nope, tell them
	RET					; return
120$:	IFNORD	SIZ=#4, ADP=4(AP), DEST=100$	; channel readable?
	MOVL	4(AP), R0			; yep! get it
	JSB	IOC$VERIFYCHAN			; and verify it
	BLBS	R0, 200$			; ok?
   	RET					; NO!
200$:	MOVL	CCB$L_UCB(R1), R5		; get the channels UCB
	DSBINT	UCB$B_DIPL(R5)			; we want no interruptions
	BBC	#DEV$V_TRM, #1, UCB$L_DEVDEPEND(R5), 210$ ; terminal, right?
	MOVL	UCB$L_TT_PHYUCB(R5), R2		; virtual terminal, right?
	BNEQ	220$				; nope?
210$:	ENBINT					; ...lower IPL
	MOVZWL	#SS$_DEVREQERR, R0		; ...tell them they goofed
	RET					; ...return
						; otherwise
220$:	MOVL	UCB$L_TT_CLASS(R2), R2		; ...get the class driver dispatch table
	JSB	@CLASS_DISCONNECT(R2)		; ...do the disconnect
	ENBINT					; ...lower IPL
	MOVZWL	#SS$_NORMAL, R0			; ...show success
	RET					; ...return

    re .44
    I had a similar program ages ago which worked fine until I tried
    it on a LAT terminal, when I got a bug check. I didn't bother
    investigating any further as the need had gone away.
    
    Andrew Palka

    RE: .31 (Am I behind on this conference!) I believe that we used to run
    something very similar to this but it was stopped after I sent sarcastic 
    replies back to the SYSTEM account at 02:31. 

    Well, the Shotgun (nee Ghostbuster) process that got rid of Chipmunk
    doesn't seem to work on the latest and greatest of system mangler
    toys, the dreaded 'secpack_ipm'.  Sound like some kind of idle process
    monitor that's part of Securpack???  Anyone have any ideas as to
    how it works, and what might be the best way to go about defeating
    it?
    
    Willie

$	SET NOCONTROL=Y
$10$:	WAIT 00:01:00
$	GOTO 10$

    re: .48
    
    	That's essentially what worked against SPIRIT and CHIPMUNK,
    but it has no effect on secpack_ipm.  Anyone know what secpack_ipm
    is, how it does it's dastardly deeds, and (most importantly) how
    to defeat it?
    
    	This is getting rediculous, COBRA (the node in question) has
    currently 18 users and 37,000 free pages of main memory.  Don't
    tell me, that just means that the foolish thing is working, right?
    
    Willie

    Not sure how it works, but you might try this,  Write a program
    that does pretty much what the aforementioned COM does except have
    it write a 0 length QIO to the Terminal.  This should keep BIO going,
    and may fool it.
    
    Also, it may just be that it has a non-zero threshold of activity
    to handle things like NOTES, A1, etc.  If this is the case, you
    just have to insure that your COM consumes enough resources to put
    you over this threshold.
    
    --  Barry

    Hmm, I'll have to look into wasting more time...  :+)  What I am
    afraid of is that secpack_ipm is not counting the subprocess resources
    in, and just sees the main process as idle, then deletes everything
    when it throws the main process off.  [seems to me this would be
    a Bad Thing to do, though....].
    
    BTW:  I shouldn't have mentioned the node name, I was trying thing
    out and my ipm_b_gone process (OK, I also should have chosen a slightly
    more innocuous name) disappeared.  I started it up again and it
    was suspended....  There's a couple of morals there somewhere....
    
    Willie

    Try making your mainprocess perform the loop, and do all your real
    work in the subprocess. If it only looks at the main process and
    ignores the subprocesses you might fool it that way.
    
    Andrew

    How do I do that?  I can't assign sys$input: and sys$output: to
    a subprocess, because 'shared files are not allowed', and I'm not
    sure that's going to work anyway....
    
    Willie

    You can share your terminal with a subprocess, I am pretty sure.
    Try this
    	$ !test-sub.com
    	$ spawn/nowait
    	$ set nocontrol=y
    	$ def sys$output nl:
    	$ def sys$input nl:
    	$loop:
    	$ write sys$output "..."
    	$ goto loop
    
    Even better, if you have Notes, TPU, or especially Allin1, go complain
    to your manager that you were using it, went to a function in your
    subprocess where you worked for a while, when suddenly your terminal
    was disconnected.(!)  Raise hell about supposed security software
    intefering with your business needs (corporate mail).  Better yet
    if you are in the field, get sales people to do this.  It always
    brings the roof down.
    
    In fairness to securepak, I think that what it does is just monitor
    the operations count on your terminal.  Thus my earlier suggestion
    to keep bumping it.
    
    --  Barry

    (Don't get me wrong now, I do *hate* spirits and the likes but...)
    
    If you have a valid reason that should exempt you from being
    killed (hmmm...) while seemingly idle then surely you can 
    explain that to the system manager. That system manager will 
    then put your characteristics in a check list for the idle
    process killer and you are happy again! Issues:
    
    - You have no good reason. Well, that's the end of it.
    - The program can not be parameterized. Well, either fix it or stop
      it altogether! You had a good reason. System management *must*
      prevent you from being zapped. They are resposable for that.
    
    Hein.

    "Valid reason that should exempt you from being killed..." What, you
    mean "I was logged in" isn't good enough? Get real! 
    
    	Jon

From SECPACK_FILES:SECPACK_DOCUMENT.MEM, section 9.2.1
    
Determining when a process is idle
      
  The measurement of process activity is a multiple of the sum of the  CPU
  time, the direct I/O counts, and the buffered I/O counts factored by the
  monitor's run-time interval.  The difference in activity between monitor
  scans  is compared to the minimum activity threshold to determine if the
  process is suspect.  When the process has been suspect for  longer  than
  the  designated  idle time, the monitor issues warnings at the intervals
  specified, then terminates the process after  the  number  of  specified
  warning messages have been issued.
  
  The warning interval also specifies how  often  the  monitor  scans  the
  system.   The  minimum activity threshold is adjusted automatically with
  the warning interval.
  
  All subprocess activity is  charged  to  the  parent  process.   If  the
  subprocess  activity  is  not  enough  for  the  parent  process  to  be
  considered active, the parent process is killed,  and  the  subprocesses
  will go away in image run down.
  
  Disconnected processes are also tracked, and will be  deleted  if  their
  activity level is less than the minimum activity threshold.


 -----------------------------------------------------------------------------

    Other information that may interest you:
        
    You can exempt users from being terminated by using the exemption
    list. It is UIC based. It allows single [33,44] or group users [33,*].
    You need privilege to run SECURPACK, option 10, suboption 7.

    IPM (Idle Process Monitor) also logs all warning messages sent and 
    terminations. Allows you to change the activity level. The rest
    of the features are similar to those found in CHIPMUNK, SPIRIT,
    or ZAP.

    Ed

    Does this mean I need to have CPU time, direct I/O, and buffered
    I/O, or will enough of one (without any of any of the others) keep
    me alive?  Also does output to NLA0: count above?  I tried eating
    a lot of CPU time:
    
    $ LOOP:
    $	WAIT 00:00:00
    $	GOTO LOOP
    
    in a subprocess, but still got logged out, though that may have
    been 'operator assisted'.....
    
    Willie

    try spawning the following loop and see if it works...
    
    $ Loop:
    $	SET TERMINAL/INQUIRE
    $	WAIT {some reasonable amount...}
    $   GOTO LOOP
    
    The /INQ will run up DIO and BIO and burn some cpu.
    

    Doug_who_once_wrote_a_Watchdog_for_his_last_employer_and_made_sure_there_
        was_an_exemption_method_and_that_I_was_exempt...

    ... and if spawning it complains, you can always just run it in
    process context while you're away from the terminal.
    
    					--D

    Or just go into NOTES. NOTES's handling of broadcasts uses a little CPU
    and a few I/Os. On a 780-class system, this is enough to stop most
    logout programs. 
    
    	Jon

    .. or start KERMIT SERver - it sends every-so-often a ^A down the
    line to synch w. another KERMIT... [which doesn't have to be there..]
    

    re .59
    
    Now that I see you can set up a loop, how EXACTLY do you get the loop
    started?
    
    Thanks!!!
    
    Don M.
    

    $! EXTRACT/NOHEAD IDLE.COM
    $! 
    $!  Define a key or a handy symbol.  When you leave your terminal,
    $!  just invoke this procedure and it should burn enough resources to
    $!  solve your problems...
    $!
    $!	It seems that SPAWNing this causes some problems sharing the
    $!  terminal so you have to stick to process context.
    $!
    $  set control=Y	! be sure we can get out
    $ loop:
    $  set terminal/inquire
    $  wait 00:02:00	! you may want to adjust this depending on your system
    $  goto loop

    But watch out, the SET TERM/INQUIRE is going to trash you're type-ahead
    buffer every interval.  That can mess you up if you're doing something
    at the time.

    	True, it will trash your typeahead but I envisioned something
    like this:
    
    	Create GB.COM as per previous note.
    
    	In your login.com put
    
    DEFINE/KEY/NOECHO/ERASE/TERMINATE PF4 @dev:[dir]GB
    
    Now when you walk away from the terminal, hit PF4 [or other key
    of your choice] and worry no more...  Of course, if you are sitting
    by the terminal, you should hear the feeps when the warning message
    arrives and do some useful work.
    
    	But... but.. I want it to work without leaving EDT (you say...)
    Well, all I can say is, Roll your own version that traps broadcast
    messages, or switch to EVE or Emacs...
    
    	Can't be all things to all people.	--Doug