T.R | Title | User | Personal Name | Date | Lines |
---|
77.1 | Not tried yet. | OPG::SIMON | | Tue Jun 01 1993 09:59 | 12 |
| 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.2 | Why remote halt? | VERMNT::coutu | He who will not risk, cannot win. | Fri Jun 04 1993 18:38 | 18 |
| 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.3 | Were talking remote management here | OPG::PHILIP | And through the square window... | Fri Jun 04 1993 23:12 | 15 |
| 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.4 | | SMURF::COUTU | He who will not risk, cannot win. | Mon Jun 07 1993 20:39 | 15 |
| 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.5 | | OPG::PHILIP | And through the square window... | Tue Jun 08 1993 10:36 | 24 |
|
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.6 | OSF/1 consoles aren't special | VERMNT::coutu | He who will not risk, cannot win. | Thu Jun 10 1993 18:22 | 17 |
| 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.7 | | OPG::PHILIP | And through the square window... | Fri Jun 11 1993 11:00 | 42 |
| 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.8 | Vote to have a break function key on OSF/1 | KETJE::SYBERTZ | Marc Sybertz@BRO - 856/7572 | Mon Jun 14 1993 13:03 | 17 |
| 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.
|