home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / stratus / 60 < prev    next >
Encoding:
Internet Message Format  |  1992-11-07  |  1.5 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!concert!ecsgate!lrc.edu!info-stratus-gate!list
  2. Newsgroups: comp.sys.stratus
  3. Subject: graph_module_usage
  4. Message-ID: <9211060443.AA22717@hydra1e.cs.utk.edu>
  5. From: shuford@cs.utk.edu
  6. Date: Thu, 5 Nov 92 23:43:38 -0500
  7. Reply-To: Info-Stratus@mike.lrc.edu
  8. Lines: 24
  9.  
  10. At my site, we have only recently discovered the 'graph_module_usage'
  11. (gmu) command in the VOS 'analyze_system' subsystem.  This paints a
  12. cute bar-graphical representation on the terminal screen of how
  13. processing power is being consumed on the module.  It reminds me of
  14. "monitor modes" in DEC's VMS.  (Oops, to be politically correct, I
  15. should say "OpenVMS".)
  16. During certain events, such as inspections of our machine room by the
  17. Big Boss, it would be neat to have a screen sitting on top of the
  18. Stratus cabinet displaying the module-usage graph.  But is it required
  19. that analyze_system/graph_module_usage be run from a logged-in
  20. interactive terminal?
  21.  
  22. What I'd like would be some practical way to have analyze_system/gmu
  23. run from a non-interactive process, only with the graph output
  24. directed to a special port to which a terminal is attached.  The port
  25. could be set to 'no_login' and no command input would be accepted.
  26. (I'm thinking of the threat to system security from a terminal left
  27. logged in without being attended to.  BTW, the display formatting for
  28. gmu seems to require a V102 or V103 display screen.)
  29.  
  30.  ...Richard Shuford
  31.     shuford@cs.utk.edu
  32.     Info-Stratus List Coordinator
  33.  
  34.