[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference share::zap

Title:	Zap Technical Conference
Notice:	ZAP Version 5.3 is available. See note 1.1
Moderator:	ZAPDEV::MACONI

Created:	Mon Feb 24 1986
Last Modified:	Mon May 05 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	170
Total number of notes:	492

54.0. "ZAP and TEAMDATA" by CGOO01::DUCHENE () Fri Oct 21 1988 12:33

    We are having a problem at a customer site here with ZAP Killing
    TEAMDATA users if they remain editing a sheet or table for more
    than the time limit.  They do get a note in the right corner of
    the sceen telling them they have a message, but they don't get out
    an read it.
    
    It looks like TEAMDATA creates a detached proccess in which it does
    all the editing work, no CPU time, Buffered I/Os or Direct I/O's are
    charged to the creating (main) process during the editing.
    
    Right now I use the .DAT file to tell ZAP to leave TEAMDATA users
    alone.  Howvever the customer would like to get rid of them if they
    are really inactive.                                          
    
    Suggestions?
    
    Thanks

T.R	Title	User	Date	Lines
54.1	Detached proc. Not Supported	MPO::MACONI	`Wed Nov 09 1988 16:05`	15
	Applications which create detached processes to perform work are poor candidates for ZAP. Since ZAP can only track usage of the main process (and any subprocesses billed to it), it will not be able to determine if the process is actually idle or active. One suggestion is to extend the limit on that application (TEAMDATA) to be more than the length of time that people spend in it. This, of course has problems, since it will kill the user after that amount of time, regardless of whether they are done or not. I can not think of any way to tie two seperate processes, which are only connected by a mailbox together. If you have any ideas... Keith Maconi
54.2	Possible answers to detached process problem	CGOS01::BDUCHENE	`Wed Nov 09 1988 17:04`	31
	The only other thing that might work is that TEAMDATA creates the detached process with the owners PID # as part of the process name. If ZAP were to look through the process names on the system looking for PID # of the process it is currently looking at it could them tell if an other process is a possible detached process of this one. It could then see if this other process is detached and if it is handle it much the same way it does subprocess ie. add the resources used by the detached process to the process it is now working on. This would add a lot of overhead to ZAP and really doesn't solve anything. If the user did hours of data entry and walks away for the time period after ZAP kills him everything he did since he last exited the spread sheet or table is gone. Maybe a better idea would be to have one more flag telling ZAP to write a meassage to the log file as if it killed the person running TEAMDATA or any other specified program but don't do the actual STOP, reset the counters and leave it. That way the manager could look at the logs weekly and talk to people. The only other thing I can think of is what we are doing now, tell ZAP not to kill TEAMDATA users. ???
54.3	Don't Zap TEAMDATA	MPO::MACONI	`Mon Nov 14 1988 15:59`	16
	Billing a process to another process via the process name has an inherit weakness. That is that a user could easily change their process name to include the pid of, say, the job controller and then become immediately immune. Probably the best idea that I can think of is: 1. Determine the image name that the detached process runs and: [,] <TEAMDATA_IMAGE> detach * /nomessage The next version, if it is ever finished, will include the logging of "inactive users" which are not actually zapped by ZAP. Keith Maconi