Well, I agree that knowing about everything that goes on behind the covers
would be nice. While I cannot give you the explanation of CP's behaviour for
this specific case, I can confirm from long experience what others have
already written: TTIME **can** (and usually will) get incremented even for
completely idle machines.
As you apparantly already know the processing of messages from other virtual
machines is one of the things that will increment TTIME. But do the exact
causes matter for you? The fact is that it works this way, and any logic you
implement to FORCE DISCONNECT virtual machines must obviously take this
behaviour into account. So, instead of looking too hard at the TTIME value
which you know to be unreliable as an 'idle' state indicator, better look
for and test things that are more reliable, such as
- VTIME
- non-spooled I/Os
- IUCV counts
- ...
If any of these are incremented there must have been some activity in the
virtual machine.
While that activity is still not guaranteed to have been initiated by the
machine's owner (I assume that your intention is really to reduce the
security exposure caused by unattended consoles), it's the best advice I can
give. Unless you find an easy way to detect attention interrupts on user
consoles ..
It's along these lines that I implemented the idle user detection code for
IBM's Performance Toolkit many years ago. Not perfect, maybe, but has been
working well in practice.
Eginhard Jaeger
----- Original Message -----
From: "Schuh, Richard" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, January 26, 2006 5:59 PM
Subject: Re: Charging Time
We do have a performance monitor, but that was not the question. Rather,
the question was, "What can be happening that would cause an increase in
VMDTTIME for this machine?"
In the case cited below, I had complete control of the CMS machine in
question and it was outwardly idle. Nothing was running under the covers
except CMS. No reader files were arriving, no messages, etc. I will try it
again after insuring that there is no SFS directory that is accessed.
Regards,
Richard Schuh
-----Original Message-----
From: VM/ESA and z/VM Discussions [mailto:[EMAIL PROTECTED] On
Behalf Of Brian Nielsen
Sent: Thursday, January 26, 2006 7:25 AM
To: [email protected]
Subject: Re: Charging Time
Tracking how many pages are resident for the userid over time would help
answer your question. If you don't have a performance monitor to give you
that info, another userid issue periodic IND USER commands.
Putting the userid in question into a disabled wait and/or CP READ would
eliminate code executing inside the virtual machine as a possible source.
If you wanted a different way to get a warm-fuzzy that it wasn't CMS
related processing, you could IPL a non-CMS system, like the standalone
loader.
Brian Nielsen
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
========================================================================
