| T.R | Title | User | Personal Name
 | Date | Lines | 
|---|
| 325.1 |  | OPG::PHILIP | And through the square window... | Mon Aug 01 1994 13:40 | 55 | 
|  | Hi,
  1) All the systems we have tried both Control-P and BREAK
     on work. Are you confusing the two, Control-P IS NOT
     THE SAME as a BREAK signal. What you have done by defining
     the "Break key" to be Control-P is effectively disable the
     sending of the Control-P character to the remote console.
     Now, are your consoles expecting "Control-P" or a
     "BREAK signal" to halt them?
     If the systems expect "Control-P" then with your configuration,
     you will not be able to halt the system as you have defined
     the Control-P key to send a BREAK signal.
     If the systems expect the BREAK signal, then what you are
     doing should work and we have a potential bug which you should
     elevate to the CSC.
  2) I am sorry, I am not sure what you are getting at? Are you
     saying that you dont see the log data for the last 'n' minutes
     when you do an extract, or are you saying that you have a chunk
     of data missing in the middle of your extract?
     I have a feeling that you are not seeing the last 'n' minutes
     of data, this is to be expected and is a feature of the way we
     try to optimize disk access when logging, effectively what
     happens is...
     PCM has a ring buffer in which incoming data from the consoles
     is stored and scanned.
     When this ring buffer fills, it is flushed to disk.
     If a user performs a "Connect" or "Monitor" of the system in
     question then the ring buffer is immediately flushed and all
     subsequent new data is flushed as it is received and scanned
     for events. This will explain why you have to "touch" the
     console in order to see data in the extract.
  Ok, We can change the behaviour of EXTRACT in order to make it
  tell the daemon to flush its buffer, however, you are going to
  have to escalate this problem through your CSC if you want to
  get it done.
  All this is irrelevent for the next version of PCM as logging
  will be done completely differently! But we are not sure yet
  when this wil be available.
Cheers,
Phil
 | 
| 325.2 |  | CSC32::BUTTERWORTH | Gun Control is a steady hand. | Tue Aug 02 1994 18:32 | 13 | 
|  |     Phil,
      The "HALT disabled" is one of perception. Ctrl P is the default
    "break" key out-of-the-box and people aren't catching that. They are
    used to being able to type CTRL-P and the system halts and I don't
    think the message "Do you want to send a break" really sinks in. We've
    had quite calls on this. Those sites that were managing microvaxen and
    are thus used to having to send a break key aren't perceving a problem.
    The sites that use "large" vaxes are. I think we should change the default
    break key to something else Ctrl-K is good as this character isn't used 
    by default for any command line editing functions etc.
    
    Regs,
       Dan
 | 
| 325.3 |  | OPG::PHILIP | And through the square window... | Tue Aug 02 1994 19:29 | 13 | 
|  | Dan,
  Thats what I thought has been happening, what I was contemplating doing for
  the next release was change it so that we dont have a "BREAK key", but we 
  have a "HALT Key" which could be defined as the BREAK-signal or a predefined 
  key sequence such as CTRL-P. This should remove the ambiguity as I think 
  its the work "BREAK" that is confusing people.
  Whadya think?
Cheers,
Phil
 | 
| 325.4 |  | CSC32::BUTTERWORTH | Gun Control is a steady hand. | Tue Aug 02 1994 23:32 | 11 | 
|  |     >This should remove the ambiguity as I think
    >  its the work "BREAK" that is confusing people.
    
    >  Whadya think?
    
    I think that is the best solution especially if it can be made node
    specific!! I've had a lot of customer feedback wanting the key to be 
    node specific as they want their operators to be able to enter the same
    key stroke to HALT the system.
    
    Dan
 | 
| 325.5 |  | OPG::PHILIP | And through the square window... | Wed Aug 03 1994 09:32 | 6 | 
|  | 
 Node specific! Sheesh, hold out crumb and you take my
 arm, OK, I'll see what I can do, but no promises.
Cheers,
Phil
 | 
| 325.6 | Use scan profile? | GOTIT::harley | Pay no attention to that man behind the curtain... | Fri Aug 26 1994 19:34 | 4 | 
|  | How about making it platform-specific (ie, use the client's scan
profile to decide whether to send a break or ^P or whatever)?
/harley
 | 
| 325.7 |  | OPG::PHILIP | And through the square window... | Sun Aug 28 1994 21:35 | 26 | 
|  | Ok,
  I'll run this by everyone before its too late!!
  I have added a "Halt sequence" item to each system record, this may set to
  either the BREAK SIGNAL or a control key (in the range CTRL/A thru CTRL/Z).
  users will have to have the "Halt system" privilege in order to halt the
  system, the connect/monitor/dialog functions will filter out the "Halt
  Sequence" if typed manually on the keyboard and will ONLY send that
  sequence if the designated HALT KEY is pressed (The halt key replaces the
  break key in the connect interface). 
  Does anybody have any STRONG objections to this, if so, speak now!!
  I think this makes it all less ambiguous removing some of the confusion we 
  have seen over CTRL/P and BREAK.
  In later releases if people can tell us wether it is appropriate, this
  "Halt sequence" could be turned into a real sequence if necessary so if
  your third party equipment needs not one character but a series in a
  specific order then this could be set up. 
Cheers,
Phil
 |