[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference csc32::consolemanager

Title:POLYCENTER Console Manager
Notice:Kits, Scans, Docs on CSC32:: as PCM$KITS:,PCM$DOCS:, PCM$SCANS:
Moderator:CSC32::BUTTERWORTH
Created:Thu Aug 06 1992
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1541
Total number of notes:6564

1441.0. "Is there a way to use Action to..." by CRLRFR::BLUNT () Wed Dec 11 1996 12:21

    
    Rather than post the entire string of notes, flames, etc., the general
    description of the customer's problem is as follows:
    
    Customer is having a problem with users logging into the monitored
    console port, working for a while, then closing the "connect console"
    window.  While they are logged in to the console, (it is OPA0) they
    usually perform a $ SET TERM/NOBROAD, essentially disabling that
    console from receiving messages from OPCOM.  Additionally, they are NOT
    logging off of the console when they close the "console window."
    
    Suggestions of the obvious (don't let 'em use it, etc) don't seem to be
    taken very well.  They're looking for a solution that they can
    automate, and my question is; can we do something using Actions or
    something else.  I guess that the preferred solution would be to
    automatically issue:
    
    	$ SET TERM/BROAD
    	$ LOGOUT
    
    to the monitored port.  Is this possible, and what might be a general
    outline of the steps required.
    
    Thanks
    
    bob
T.RTitleUserPersonal
Name		DateLines
1441.1CSC32::BUTTERWORTHGun Control is a steady hand.Thu Dec 12 1996 12:4618
    Yes,
      You could use the DIALOG interface to first UNLOCK a console and then
    send the REPL/ENABLE and LOGOUT commands. The final problem to solve is
    how do you know when someone is connected and actually working? You
    could do 
    
    DEFINE/USER SYS$OUTPUT CONNECT.LOG
    CONSOLE STATUS/SYSTEM=system-name
    
    and then parse the oputput file for the line
    
    In use by .........:
    
    but this is rather dirty. There is currently no API routine to check to
    see if a user is connected. It would be a real handy addition though.
    
    Regs,
       Dan
1441.2how about...CRLRFR::BLUNTThu Dec 12 1996 17:5410
    
    Can it be done as part of the "disconnect" process, as this seems to be
    the point of failure.  Someone does a login, disables broadcast, then
    just does a <CTRL>E when done.  I guess that they have the thought that
    either "I'll be right back" or that they process is logged out like
    when you terminate a DECterm.
    
    Gotta go claim my cookie...
    
    bob
1441.3CSC32::BUTTERWORTHGun Control is a steady hand.Fri Dec 13 1996 11:0316
    >Can it be done as part of the "disconnect" process, as this seems to be
    >the point of failure.  Someone does a login, disables broadcast,
    >then just does a <CTRL>E when done.  I guess that they have the thought
    >that
    > either "I'll be right back" or that they process is logged out like
    >    when you terminate a DECterm.
    
    There's no way to do this right now. Even if you change the CONNECT
    interface to send a "logout" command upon disconnect there's no way
    to guarentee that the process is logged out. This is becuase there
    is no guarentee that the process was left with the shell or CLI prompt
    and ready for a command.
    
    Regs,
       Dan