I understood and was offering one way to begin the process of elimination in order to isolate the cause(s).
As others pointed out, just because a CMS user isn't interacting via the terminal does not rule out a behind the scenes CMS process. A resonable first step is to determine if it from CMS, as some posit, or from CP as you positted. Trying to rule out various CMS causes is premature if CP is the cause. Brian Nielsen On Thu, 26 Jan 2006 08:59:58 -0800, Schuh, Richard <[EMAIL PROTECTED]> wrote: >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 >>========================================================================
