Conference iosg::all-in-1_v30

    Yes, I remember this being discussed here before.
    
    I don't think anyone ever found out what was causing it....
    
    Graham

Hi,

If someone is in ALL-IN-1, and doing nothing, then presumably the cursor is
sitting on the CHOICE field of a menu (or any field of any form! :-)

In that case, FMS has control, not ALL-IN-1, and FMS is just sitting there
waiting for input.  Normally you'd expect the process to just sit in a wait
state until the input arrived.  However, it looks like (mere speculation on
my part) FMS is periodically waking up and doing "something" before
waiting for input again.

It could be something as simple as just setting a timeout on the input request,
then when it times out FMS looks and sees there's no input, so loops round and
waits again.  It wouldn't surprise me if it does this because of some
restriction of I/O operations in the Ancient Days when FMS was made.

Sounds plausible?  Unfortunately I don't think there's any such thing as an
FMS engineer any more to give a definitive answer.

Scott

... or it could be the CPU generated while you are using MONITOR to see how
the processes is behaving. An AST is generated within the context of the
monitored process, when you query what it is doing by, eg, MONITOR.

Maybe the CPU generated by the AST while a process is running an image (in
USER mode) is greater that the CPU generated while it is at DCL (SUPERVISOR
mode).

Just a thought!

mb

    Hello                            
    
    Actually, I want to find how ZAP (that kills idle process) can zap
    idle ALL-IN-1 user.  Since the process consumes a little CPU even when
    idle, so ...
    
    I suppose I am not the first who encounter this problem!
    
    Thank you very much
    Banquo

When a system is running ZAP, or any other idle process killer that uses the
SYS$GETJPI system service, then small amounts of CPU time will be accumulated
when a process is monitored.  This is due to the special kernel mode AST that 
$GETJPI uses to pass the target process' statistics to the calling process.
The AST is fired in the context of the target process, and it must be COMputable
to do it.

The idle process killer takes this small amount of CPU into account when 
deciding whether a process is idle or not.

FMS, SMG, DECforms, and all other terminal software use the $QIO mechanism.
When a read I/O is queued to the terminal, the process enters the LEF state
(Local Event Flag wait) and stays there except for short hops in to COMputable
and current states to deliver ASTs (for instance). If the process was planning 
to wake up from time to time, it would be in HIBernate state.

Finally, MONITOR, SPM, VPA, and DECps do *not* use the $GETJPI mechanism to 
track system resource consumption.  When extended process statistics are asked
for in DECps (for instance), it will elevate to a higher IPL and walk the PCB 
list and pull whatever information it wants out of the processes directly.

Regards,

Marc

    Hello
    
    The cause is the client complaints that ZAP cannot kill idle ALL-IN-1
    user but can kill idle DCL user.  So I use "SHOW PROCESS/CONT" to take
    a look at two processes, one is idle in ALL-IN-1, the other is idle in
    DCL, found that the one in ALL-IN-1 will consume CPU while the one in
    DCL does not.
    
    So is there some ways to make ZAP kill idle ALL-IN-1 user beside
    lowering the idle time-limit to less than half an hour. (Why half an
    hour -- because I found from show process/cont that the idle ALL-IN-1
    process consume .01 sec CPU about every 30 minutes)
    
    Thank you very much
    Banquo

    Hi Banquo,

    ZAP is in use on all six of the Southern States Region's ALL-IN-1
    OpenVMSclusters, and has been for several years, doing what it is
    intended to do; our inactivity timer is set at 20 minutes.

    You might want to check in the ZAPDEV::ZAP VAX Notes conference
    (press KP7, etc)

    Hthy,

	Ron

    Hi Banquo,          
    
    All the replies in here have mentioned the fact that monitoring a
    process causes the monitored process to clock up CPU time.  This is
    correct.
    
    DECUS have a process "killer" called WATCHDOG and in the bad old days at a
    site where I worked none of the processes that had been inactive were being
    "killed".  To get around the problem we changed the code for WATCHDOG to 
    monitor the IO's. If the IO's did not change than the process was "killed".
    
    Monitoring the CPU time is not the correct way to determine if a
    process is inactive, where as we found that IO's gave us what we required.
    DECUS for a cost of a tape provided the customer with WATCHDOG the kit 
    included the source code and documentation.
    
    Sunil