Conference csc32::consolemanager

    Simon ,
    
       You'd be far better off asking this question in the VCS notes file.
    It has more readers.
    
    Dave

    Simon,
    
       Given the progression of lights-out operations, isn't remote CONTROL
    vital? I feel that the question of weather to provide remote HALT is
    a non-issue. Of coarse, the functionality is required. My vote is to
    add this capability.
    
                Regards,
    
                Robert Beazley
                Digital Solutions Center, New York City

I agree with .1.

If we are producing a 'Console Manager', one of the major requirements is to be
able to issue a BREAK when required. Admittedly internal to DIGITAL, I know of
several sites that will not implement Polycenter Console Manager because it
cannot issue a BREAK or emulate the console (although I know the latter is
coming).

Martin

Hi,
   in reply to the item below:

>I agree with .1.

>If we are producing a 'Console Manager', one of the major requirements is to be
>able to issue a BREAK when required. Admittedly internal to DIGITAL, I know of
>several sites that will not implement Polycenter Console Manager because it
>cannot issue a BREAK or emulate the console (although I know the latter is
>coming).

>Martin

Console Manager can issue a Break to a managed system on any of the supported
connection types.

The only restriction at the time of release was which of the terminal servers
you may have been using actually relayed the breal on to the connected system.

The major problem was that the DECserver300,DECserver 90TL and DECserver 700 did
not support a Break delivered from the TELNET listener. We would send a Telnet
Break protocol message, but the server would ignore it. 

THIS HAS NOW BEEN FIXED with the Network Access Software. So if you now have a
DECserver 90TL DECserver 90M or a DECserver 700 WHICH RUNS the NAS then you have
break capability over TELNET.

The only only issue then is whether the managed system does anything with the
Break. Currently only some of the AXP boxes have any facility to halt them when
running OSF/1 which is where the base note comes in.

Hope this clarifies this point.

About the REMOTE CONTROL and CONSOLE EMULTAION statements. What do you exactly
mean by this? Is not the ability to halt the system a major part of full CONTROL
of a system?

Cheers Simon....

    My customer is a large agency with the DoD and SUN reigns big-time. 
    The customer is currently undergoing evaluations of a variety of
    vendors software and hardware products that would ease their transition
    to a more centralized operational environment.  There are times when
    the customer's software hangs the system (currently runs on SUN, IBM,
    HP, and DEC (Ultrix only right now)) and the only way to reset the
    system is issue a HALT.  The SUNs permit a HALT from the keyboard,
    which comes in very handy when your operations center is in a different
    building than the actual system.  The customer is looking very hard at
    DEC POLYCENTER products, one of which is POLYCENTER CONSOLE MANAGER. 
    VAX/VMS systems permit a keyboard HALT which can be issued via the CM
    software (the customer likes VAXes) but DECSTATIONS do not (they don't
    like the DECSTATIONS).  Unfortunately, the customer doesn't want to use
    VMS, but wants a UN*X solution. The customer would like to integrate
    ALPHA systems running OSF/1, but if the use of the ALPHAs under OSF/1
    do not allow HALTs from the keyboard, other vendor's systems will be
    considered.  My customer would love it if OSF/1 permitted keyboard
    HALTS, and the ability to separate the system console from the
    workstation screen via a hardware switch like the VAXstations do.
    

    
    
    Remote break (=remote HALT) is absolutely needed. Even system
    hangs are very rear it is needed. We have now one system
    (VAX 3100-80) connect via CISCO terminal server to CM and
    remote break dosen't work  with CISCO terminal server. 
    (there is also other problem  see other note in this conference)
    To make S/A backup for example is not possible without local
    intervention. 
    
    -Olli
    

    The Royal Hong Kong Jockey Club (one of Digital's top 20 customers) is
    basing its entire operations strategy on auto ops. They intend to go to
    Unix, obviously an ability to remotely halt a system is very important
    to them. They will not be impressed if this does not happen, as they've
    just been stuffed by POLYCENTER Netview - two home goals in a few
    months doesn't go down well.
    
    Martin

Luxair at Luxemburg requests the halt break function to work under OSF/1 AXP.
They need a operator less environment ... How can you provide an operator less
environment if you request someone to be in the computer room in order to halt a
system ?

Marc.

Ps : In all RFP (Request for Proposal) we answer, we include the Console Manager
with this functionnality ... Just because it has no sense to not having it when
you speak about decentralized computing centers.

        C'mon, you guys. Let's be reasonable. It's either a remote break
    or a RS232-controlable robot arm ($459.99 in kit from Radio Shack 8^).

        Seriously, for people using the console port, you might want
    to provide a console variable BREAK_FROM_SERIAL_CONSOLE_PORT_ENABLE,
    accepting TRUE or FALSE, to provide different kinds of behaviour.

        Let us put an end to this discussion. I today's environment,
    it is ESSENTIAL to have a remote halt facility. Period.

        Mike 

Re .-1


Beleive me there is nobody in the CM engineering or marketing team who disagree
with you.

The problem is that you have to persuade the product managers of the operating
system engineering groups that it is worth the effort of doing in $$ and
customer satisfaction!!!!

This note was not a Discussion it was to try to get quantifiable data to pass to
these people.

So can you put any real cases/cash behind this reply.

Cheers Simon.......

    This is a must!
    
    The CAATS project($400M) in Canada requires remote control over all
    processors.  This includes the ability to halt the processor from a
    remote site.
    
    It seems strange to me that we are even having to put such a case
    together.  We ourselve are preaching lights out computing to reduce
    costs and aid in downsizing.  A key component to lights out computing
    is the ability to remotely have complete control over the processors.
    
    
    Jim

    This discussion has also taken place recently in the DWT or Alpha_OSF
    notesfile.  Basically, you can't implement a distributed client-server
    environment without this.  The fact that OSF, or whatever, product
    management doesn't realize this implies that the field/customers will
    have to educate them too much on this, and other more fundamental issues
    to be successful.   If they need to see multi-million $ customer losses
    to understand that system managers are NOT going to wander around the
    corporate campus or city to get to a keyboard then they have not woke
    up to the '90s.

    I agree that it is very sad that this discussion even is happening.
    It is inane to have to even make a case. It should be very apparent
    to the engineering groups/leaders. If it isn't then another nail
    is being driven into the coffin.
    
    Sorry for the oration but this company wastes more time on efforts
    like this.
    
    Jim C.
    

Hi Simon,

What is the current status of the Remote Halt Capability?

Thanks,
jim

    Jim,
    
       Simon's gone home for the evening and perhaps he can shed some more
    light when he gets in. Anyway, this is one of the top 2 issues on our
    list. Unfortunately, we are at the mercy of others in getting this 
    resolved and to date, there has been little commitment from others to
    get this done.
    
    Dave                   
    

I just want to add a vote and tell how important HALT functionality is for both
my customer and support.

My customer is using VCS(VAXcluster Console) today to manage all his major
VMScluster nodes, but they have decided to move to UNIX. They have systems in 3
different sites connected with FDDI, and MUST be able to HALT the systems from
the remote console sw. 

In addition to the benefits for the customer, I think such functionality will
save Digital support money to. This functionality means that we are able to have
full control over the customer system(if permitted/needed) from our office. This
will save us both time and travel expenses. It could also give the customer much
better support, because it's "always" easier to see/do it yourself...

\�ge

    
    HP9000-800's can be halted remotely (CTRL-A or CTRL-B). It should
    quite funny during PCM demos when customers asked what can be done
    is system is hanging. With VMS systems and HP9000-800's you can halt them
    and reboot but for OSF/1's someone  has to go on site.
    
    -Olli
    
    
    

The OSF cluster product requirements lists support of PCM as a high priority.

I have recently had an exchange with someone in OSF engineering who responded
that this would have to come thru OSF product management. I'm assuming that
OSF product management didn't agree with your product management a year ago.
However, Paul Steeves is now involved as OSF cluster product manager and
I will be working to ensure the correct message is given to engineering.
We in CVG need this support and as a qual engineer for OSF clusters I see
this as critical.

However, I would like to ensure that my message on what is required by PCM
in the DEC OSF software is consistent with what you say is required.

(CVG has been using VCS for 6-8 years to manage clusters, so I think that
we understand the requirements, but this appears to be a touchy issue with
the unix folk, so I want to be sure the words are right and consistent.)

Please contact me by mail.

BTW, I'm not sure exactly what the issue is, but I'm sure that it has more
to do with religion than science.  While the Alpha platform architecture
places the responsibility on the hardware group, which is also responsible for
firmware, the osf group decided to bypass the palcode when accessing the
console.  What I'd like to do is remove all alpha systems from people's
offices and place them two building over....that would certainly result
in a religuous conversion.

    What's the current status of this issue?  I have a bunch of Alphas that
    I will connect to PCM, and will want to be able to remotely halt them.
    
    As a sample, how about:
    
    AlphaServer 2000 4/133 running Digital UNIX V3.2c
    AlphStation 400 running OpenVMS Alpha V6.2
    
    Thanks!
    tl

    We still can't halt the Digital Unix box but it's no problem halting
    the OpenVMS systems.
    
    Regards,
       Dan

Are we still waiting on Digital UNIX?

Anything new?  Any update?

Bruce
MCI Account Team