Conference csc32::consolemanager

301.0. "MONITOR CTRL/S Stalls Console Output" by BSS::LIND (Jim Lind; 592-4099 CX03-1/N14 CNMC-West) Tue Jul 12 1994 19:31

    WARNING:    Users MONITORING a node should NOT enter the HELP command 
    		and then leave their window at the HELP screen.  Doing 
    		so will STALL the command mode user and output from the 
    		node being monitored will STALL, no longer going to the
    		log file.

    		CTRL/S has the same effect.

    I am having a problem with the MONITOR function while another
    user is performing a CONTROL function on a PCM node.

    FIRST USER - COMMAND MODE - enters command to create continuous output:

    	$ DIRECTORY SYS$SYSTEM:/FULL

    SECOND USER - MONITOR MODE (of same node) - enters HELP at command
    prompt and just sits there ...

    The output on the FIRST USER screen will pause until the SECOND USER
    response to the help text.  If the MONITOR user leaves his screen
    PAUSED (x-offed), the COMMAND function will be STALLED.

    Fist (COMMAND) user can CTRL/E to EXIT - works OK, but node remains
    LOCKED.  Any attempt to UNLOCK the node (by prived user), hangs
    that user (UNLOCK pending, screen not painted/updated), until the
    MONITOR user releases his pause (CTRL/Q or clears HELP function).


    APPARENTLY, any user that is MONITORING a node and enters help or
    CTRL/S (freezing his screen output) will cause the CONTROL user to hang
    also.  THIS IS A SERIOUS PROBLEM, since MONITOR users should NOT
    be able to STALL command mode users or force termination of output
    to the console log files.  

    SYSTEM HANGS CAN BE CAUSED BY THIS SITUATION ...

    If the situation where console output is paused/stalled were allowed to
    continue, eventually the OPCOM process on the system being monitored
    would hang when the OPCOM process exceeds BYTLM quota.  This could
    then hang the AUDIT SERVER process that must communicate with the OPCOM
    process, which in turn COULD cause processing on the system being
    monitored to STALL.

    Jim Lind

Jim,

  It appears that you have found a design deficiency in the
  way that the Monitor interface was built. I can not offer
  any workaround for you except to warn all your users. Also,
  because of the way the Monitor interface has been written,
  this is not something which is easy to fix, so dont expect
  to see a "patch" to fix this, it is more likely to appear
  in the next major PCM release where we can redesign and
  build the monitor interface.

  What is supposed to happen is as follows...

  When data is detected from a managed console by its controlling
  daemon, this data is logged to disk and forwarded on to any
  monitor/connect session which is "viewing" that system.

  Now, the monitor session is reads this data and displays it for
  you, which most of the time it does.

  However, if (as you found out) you type "Help" or CTRL/S then you
  actually leave the PCM "mainloop" (which reads the data from the
  daemon and processes it) and enter the VMS Help system (man page
  stuff on Unix) the monitor session is unable to process the new
  data from the controlling daemon. This daemon now fills its buffers
  and stalls, I would guess at this stage it is in RWMBX state.

  Thanks for letting us know about this.

Cheers,
Phil

    >design definciency
    
    Now if you'd let me at that build system I'd be happy to fix it.
    
    
    HINT HINT HINT ;-}
    
    Dan