We ran into surprising charges to TTIME in using ESAFORCE and before that OMEGAMON to force idle users. Users are often not idle if you look at TTIME.
When a file is added to a user's reader, there is an interrupt. CMS doesn't do anything with that interrupt (unless you use WAKEUP or a PIPE to wait for reader files). I think time gets charged to both VTIME and CPTIME in this case but I'm not sure. (TTIME = VTIME + CPTIME.) Any message displayed on the user's console by CP causes a charge to CPTIME. (That includes CP MSG from another user.) I think any interrupt would also cause a charge to CPTIME. I'm sure there are other examples. I think that any time that CP does anything on behalf of a user there will a charge to CPTIME. But I don't know if page steals count as "on behalf of a user". I think it should be charged for this because the idle user is hogging the page, so why shouldn't they be charged for saving it's precious contents to DASD? But that doesn't prove anything; I haven't read the code. On Wed, 25 Jan 2006 13:08:21 -0800, Schuh, Richard <[EMAIL PROTECTED]> wrote: >Is the time spent stealing pages charged to the user whose pages are being >stolen? If not, what else can add to the TTIME of an otherwise idle user? > >Let me set the stage. We are being required to FORCE DISCONNECT any user who >has been idle more than x minutes (x still being debated). Trying to test the routine that does this, I logged on a general user and let it sit idle after falling through its PROFILE. It remained connected, so I could see that there were no messages being received that might be counted as TTIME. This user stayed connected for nearly an hour longer than the specified limit. In reviewing statistics gathered using ESAMON, there were several times during the period when the reported VMDTTIME was incremented, which in turn, caused the idle clock to be restarted. After several resets of the idle value, the user finally timed out and was disconnected. When ESAMON reports TTIME to the macro being used, it converts VMDTTIME to a decimal number rounded to 10000ths of a second, so these periodic increments were stepping in 10ths of milliseconds, not insignificant values for a z990. > >This happened fairly early in the morning. We do not observe anything like it >when we reach our normal daytime load. That is what made me think that it may be page steals. The rationale is that the pages are stolen more quickly when the machine is loaded, so they are all stolen very early in the idle period, not causing a noticeable lengthening of it. With a light load, there is much less a reason to steal pages; therefore it takes a much longer period to steal all of the idle user's pages and they are stolen in small clumps at random times, accounting for the unevenness of the incrementing of TTIME. > > >Regards, >Richard Schuh >=========================================================== =============
