[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

77.0. "CM works with DEC 3000/500" by KETJE::SYBERTZ (Marc Sybertz@BRO - 856/7572) Fri May 28 1993 20:56

My colleague just told me that he tried to boot a 3000/500
OSF/1 with a vt340 as console, while the X came on the
graphical screen. It was running fine ...

So it's now possible to manage the console of one of the
workstation we sell.

Anyone knows about the 5000/300 and 5000/400 ?

Marc.
T.RTitleUserPersonal
Name
DateLines
77.1Not tried yet.OPG::SIMONTue Jun 01 1993 12:5912
Marc,
    yes we have a 3000/500 and have had it working, but have not had access 
to the others yet.

 The only issue we are looking in to is halting the system remotly. If the 
AXP is running OpenVMS a ctrl P will halt it. Under OSF/1 this does not function
as the halt procedure is built in to the platform specific PAL code. 

If you can site cases where this is a problem let us know as we are trying to
put a case to the OSF engineers to get it fixes.

Cheers SImon...
77.2Why remote halt?VERMNT::coutuHe who will not risk, cannot win.Fri Jun 04 1993 21:3818
I don't understand why you need to be able to halt the system remotely
without access to a priveleged account on that system?

I have never understood why VAX systems allowed this. It seems like a
majorly wrong thing to do. Any joker with access to the console can
stop the whole system without a clue as to what processes are actively
running? Seems fishy to me.

I suspect that you won't get OSF/1 folks to agree to put in the ^P.
I know I wouldn't support it and I'm trying to determine how I can
use your product to help us test the installation of OSF/1 on our AXP
systems!

Complex operating systems like VMS and OSF/1 should always be properly
shutdown in order to insure that the buffer cache of file data is always
written to disk. This avoids disk corruption and is important.

Dan
77.3Were talking remote management hereOPG::PHILIPAnd through the square window...Sat Jun 05 1993 02:1215
Dan,

  I hear what you are saying, and understand where you are coming from.

  However, what does a system manager do to stop a system which is say
  running a process in a tight cpu bound loop at high IPL when the
  system manager is doing his management task from several hundred
  miles away? The system may in fact be hung for some other reason
  such as insufficient resource to continue and needs to be halted,
  now with VMS you have AMDS to help you out, but on OSF/1 you have
  nothing.

Cheers,
Phil

77.4SMURF::COUTUHe who will not risk, cannot win.Mon Jun 07 1993 23:3915
    Ah, now think I see. I had not considered that someone would actually
    consider it feasible to have a system setup that had NO physical
    access. I was assuming that it is always possible to hit the reset
    switch on the back of the system even if you have get a non system
    manager type to do it. I can accept that may not be a good assumption.
    
    The sticky point I see is determining how to introduce a special way
    to access console mode. ^P won't work well since numerous editors
    on OSF/1 use it. In fact almost every control code known to man is
    used by emacs! :-) (Can you say user friendly?)
    
    So how can you get useful work done and still allow some special back
    door to the console?
    
    Dan
77.5OPG::PHILIPAnd through the square window...Tue Jun 08 1993 13:3624
  I can understand the problem for OSF/1 users, but, how often
  does someone edit on the console (I thought that this was not
  a recommended practice, although I must admit, I dont know
  where I got this idea from) after all, arent console devices
  traditionally hardcopy terminals (I know some banks prefer
  hardcopy devices because then they have a physical audit
  trail). Anyway it doesnt have to be ^P, we would prefer that
  because VMS uses it and so the company would have a common
  methodology for halting all its operating systems (it could
  be Ctrl+Alt+Del for all I care).

  Of course, if you are in the business of writing operating
  systems/device drivers etc., you may spend long lengths of
  time at the console editing/debugging, but how many people
  actually do this?

  We, with Console Manager are trying to cater for the mass
  market, the one out there running customers business systems
  where the console is used as a console and not just another
  terminal.

Cheers,
Phil
77.6OSF/1 consoles aren't specialVERMNT::coutuHe who will not risk, cannot win.Thu Jun 10 1993 21:2217
Well it's like this:

The VAST majority of systems running OSF/1 are workstations. The user
logs in on the console constantly! The console is the graphic display,
yes the same one the user puts windows on. OSF/1 users expect the
console to behave just like any other terminal on the system. The only
difference is that it may get extra messages showing up on it and it is
the only active terminal when the system is in single user mode. That's
it. There is no taboo against using the console for normal work. I
rather suspect that most people using any kind of UNIX are rather more
frugal in their equipment buying habits than VAX users. They have a long
history of getting of getting a lot of functionality for a little money.

Does that help?

Dan

77.7OPG::PHILIPAnd through the square window...Fri Jun 11 1993 14:0042
Dan,

  It helps and I am in total agreement with you, however,
  not all workstation users are experienced UNIX/OSF/VMS
  system managers, this aspect of the management of their
  workstations is done by an I.T. department. Now, with
  the recent downsizing trend, multinational (or even
  large national) companies want to have one central
  I.T. department which is small and well equiped to
  manage the whole distributed enterprise. This is where
  access to a serial console device is required (hence
  Console Manager). With the current behaviour of OSF/1
  (and ULTRIX incidentally) on our DEcstations, we cannot
  satisfy this customer requirement. Our competition
  can with their U*x variants, consequently, we are
  not losing Console Manager sales, but we are losing
  DECstation sales!! now, which makes the most money
  for the corporation?

  This also applies to servers, not just workstations
  because we cannot halt ANY of the AXP systems running
  OSF/1 because of the way the OSF PAL code works. I can
  imaging the customers reaction when we sell the a couple
  of AXP systems with OpenVMS and OSF/1 and they cant halt
  the OSF system remotely!! Methinks we stand a good chance
  of losing the sale.

  We also have a problem with these newfangled Windows NT
  servers, we cant manage those remotely at all!! And how
  often do you have your PC lock up on you so that you have
  to hit the reset button? - This is probably a topic for
  another time (although we probably need to do something
  for the AXP NT server boxes, now that would be digital
  added value).

Cheers,
Phil





77.8Vote to have a break function key on OSF/1KETJE::SYBERTZMarc Sybertz@BRO - 856/7572Mon Jun 14 1993 16:0317
CM with no 'remote halt function key' looses a lot of interest in managing
remote machines.

I totally agree when you say :

>  Our competition
>  can with their U*x variants, consequently, we are
>  not losing Console Manager sales, but we are losing
>  DECstation sales!! now, which makes the most money
>  for the corporation?

So I definitively vote to have it but as Dan points out, most of the control
key are used by Emacs. 

We definitevely need IT.

Marc.