Conference wrksys::alphastation

   This looks like the classic <BREAK> problem found on MicroVAX systems
   of old -- when one powers up (or down) serial communications equipment,
   the equipment can incidently transmit a framing error, and another name
   for a framing error is <BREAK>.

   I'd try the alternate port of the AlphaStation, or disable <BREAK>
   processing on the console port (this is possible only on a very few
   Alpha systems -- the alternate to <BREAK is <CTRL/P>), or I'd not
   shut down the serial device (the PC, in this case) on the console
   serial line...  Some sort of serial line filter might also be possible.

John,

The character being sent by the PC may be a CTL-P. The console interprets
this character as a HALT command. The CTL-P is a very simple sequence,
and it can easily be generated by dumb luck during the power-down.

Put the PC on COM2, which doesn't have this problem,
      or
ask VMS for COM1 support without callbacks (in V7.1? see note 1540.3),
      or
ask us for a console feature that supports disabling of CTL_P
      or
live with it as it is.

If necessary, please escalate this through official channels to make sure that
it gets done.

--RS

    >>>    The console is a PC running
           ^^^^^^^^^^^^^^^^^^^
    >>>    a DOS terminal emulation application, called Possum.  The COM1 of the
    >>>    PC is conected to COM1, or OPA0: of the AlphaStation, which has the
    >>>    console set to the serial port.  No Graphics adaptor is installed.
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    
    This isn't "fixed" in V7.1.  V7.1 changed the way that OPA1 was handled
    by making it a TT device instead of making console callbacks.  In the
    case described here, the device is OPA0 -- that is, the console.  In
    which case we always make console callbacks, and the ^P or break
    detection is done by the console.
    
    Given that this is explictly the console (not just a serial line app)
    then the only answer is to change the console to allow ^P/break
    detection to be disabled.
    
    _Fred

    hi,   we have a alphastation 200 srm ver6.3-4  and
    alphastation 255 srm ver6.3-2 and both use serial consoles.
    
    they both seem to have console paramater CONTROLP and is set to ON 
    by default.
    
    if i do >>>set consolep OFF  >>>init and start booting vms V6.2-1h2
    i can hit ctrl p and it no longer halts the cpu.
    
    this may help with the problem?? i dont know if it will stop the
    halting by powering off the terminal and it sending out a
    <break> guess it would if it looks like ctrl-p
    
       jim hutmacher mvhs colorado csc 800-354-9000 ext 25561 

    Hi team!
    
    Thank you for the invaluble input.  I forgot about the break key.
    
    Moving the PC to COM2 is not a viable option, as we do need a console
    on COM1.
    
    We did find a wiring problem.  Somebody mistakenly thought pin 7 was
    ground on a 9 pin sub D connector.  The customer is frantically working
    to fix this on their 6000 systems.
    
    I am courious...  did .2 & .3 state we could make some code changes to
    SRM to prevent inadvertant ASCII strings from effecting the console?
    
    I am going to present .4 to the customer.  I wish we could consistantly
    replicate the problem.  >>>set consolp OFF looks too good to be true!
    I will post the results!
    
    Best Regards,
    John
    

re .2 

The console code change to which I was referring is support for the
"set controlp" command. It's good to hear that this functionality is 
there. I was told earlier that this command was not implemented on
some of our machines, and I jumped to the conclusion that the
machines in question do not support it. Sorry.

When Set Controlp is OFF, bad character sequences on the console port
will not have any ill effects on the console firmware or the hardware.

--RS