Conference csc32::consolemanager

Mike,

  Thanks for your comments, I agree with some, however, let me take your 
  comments one by one.

>> My first DISAPPOINTMENT was not seeing any event or scan profiles! As you
>> are no doubt aware the present VCS profiles are badly outdated. There are
>> no scan profiles for the 7000s, VMSV6 (such as fatal bug checks), HSJs
>> OSF/1 machines etc etc. Also, a number of them no longer work. In my opinion,
>> NOT providing the proper profiles are a serious deficiency in the product.
>> Lights out Data centers have developed a reliance on VCS, no-one has time to
>> monitor consoles anymore. We have the expectation (and trust) that VCS 
>> or Console Manager will tell us of problems.

 This has been discussed many times over, you should raise this issue not 
 with use the engineers, but with product management, I suggest you mail Rae 
 Kung (MUZICK::KUNG) and give tell her your problem. We have been doing this 
 since we shipped V1.0 of PCM, but we dont seem to be able to get either the 
 right people create the scan profiles (the respective h/w or s/w engineering 
 groups) or even get funding for people to create them for us.

>> This conference is littered with requests for updated scan profiles. The
>> typical retort is that profiles are best managed by the various development
>> groups as they know the messages better. To that, I'd say YES of course
>> solicit the help of these groups to validate your profiles and maybe even
>> negotiate with them to have them take on this responsibility but you can't
>> just drop support for scan profiles from the product without first making
>> these arrangements. Sure it's a considerable task to built these profiles
>> but better you than ALL of us users.

  I am glad you agree that the profiles are best managed by the various 
  development groups, perhaps it would help them understand your problem if you 
  asked them for scan profiles just like we have been trying to persuade them 
  to. We have offered to act as a repository for the profiles and ensure that 
  they work correctly with PCM.

  We didnt just "drop support" PCM never really had any support, we included 
  the VCS profiles in V1.0 on ULTRIX because we were told too, after realizing 
  that they were vastly out of date we decided not to include them in V1.1 
  onwards as to include out of date profiles would cause more support calls 
  than not including any.

  I disagree that we are the best people to provide these profiles, we dont 
  know what you want to scan for, nor do we know how important those events 
  are, you are the best judge of that in your environment.

>> I have to say the VCS to CM conversion process leaves a lot to be desired. The
>> CONSOLE$VCS_CONVERT is good but it has a number of limitations, now of which
>> are documented in the release notes or user's guide conversion section.

  We know it isnt perfect, but when you have limited resources, we felt that 
  spending time on the rest of the product was better than improving an image 
  which would probably be executed once on any given site where the output of 
  the image was going to be edited by the user anyway. (After all, when only 3 
  engineers work on the product, there is only so much we can do!).

>>   - it perpetuates fragmented scan profiles, VCS had a problem in that larger
>>     scan profiles had to be fragemented, CM solved this problem, it would have
>>     been nice to know this before applying the .PORT file so that edits could
>>     be made to organize the scans profiles better.

  The idea was to get the customer up and running, we cant second guess why 
  the customer had multiple profiles, they may have been there for a reason.

>>   - a number of events (ACTIVE IDLE LINERR OFFLIN) (these are no text events)
>>     and the scan profile _SCAN$EVENTS are VCS specific, these are converted
>>     as well and don't need to be, I have since edited them out but if I had
>>     known about them in advance, I would not have applied them to begin with

  I agree, these events should have been removed, this was an oversight. It 
  actually causes other problems for the product too which have only recently 
  come to light!

>>   - priorities are handled differently, if the conversion notes had told
>>     me this I would not have ended up with so many mis-classified events,
>>     many low priority events were given clear or indeterminate priorities,
>>     you should have at least warned people of this.

  Didnt you read the manual as well as the conversion notes, the manual 
  clearly states that there are only 6 priority levels. I think the upgrade 
  also asked you to review the output of the conversion process.

>>   - it would have been nice to provide a procedure to remove the VCS software
>>     from the system

  I agree, another oversight, we were actually thinking that people might 
  want to get to their old VCS data for a period, but didnt really consider the 
  eventual removal of the VCS product. Have you already done this, do you have 
  a procedure you could share here so that others could use it?

>>   - we use VCS to provide us with a historical record of the console activity
>>     for audit requirements. I could not find a way to review old VCS logs
>>     (without maintaining a VCS system). 

  This is why we didnt remove VCS as part of the install of PCM. 

>> o The installation asks a question about British UID but there are no
>>   explanations to help the installer decide if they want this option

  A shortcoming of the documentation, we naively assumed that the installed 
  would typically be a system management type and would know all about 
  DECwindows and language specific UID files.

>> o When you use the Console editor in character mode and type the MOD
>>   SYSTEM 'system' function, the case of the system name is changed to
>>   whatever you specified as the system

  A bug, I will look at getting this fixed.

>> o When you do SHOW commands under the Console editor it always prompts for
>>   2 things. (Full or Brief listing? and Output file (SYS$OUTPUT)). This is
>>   not the way VMS commands are supposed to work. This is a throwback to
>>   Ultrix or something. If the user wants full or redirected output, let them
>>   pass a qualifier

  This is intentional, I am sorry you expect the VMS style of /this/that and 
  /theother but the product runs on 4 different operating systems and so to 
  keep maintenance to a minimum we have to pick the lowest common denominator, 
  now if you pesuade OSF/1 and ULTRIX to implement a cli like DCL on their 
  operating systems, we can do something for you.

>> o In VCS when you did a SHOW SCAN you were shown the whole scan tree. Is there
>>   a way to do this in Console Manager without having to enter recursive
>>   commands?

  A shortcoming in the product, I will add this to the wish list.

>> o Under the configuration editor you can only apply modifications in prompt
>>   mode, what happened to being able to do modify entity commands?

  Same reason as to why we prompt for brief and full, no cli on the Unix 
  platforms. You will in fact be better off using the DECwindows editor, it
  is much more flexible and is in fact the preferred mechanism for editing
  the database entries.

  Phew was that all you could find, I hate to think what you are going to say 
  when you start **using** the product. Where were you when we did field test, 
  this is the sort of feedback we could have done with then, however it is all 
  useful for V2.0. Thanks.

Cheers,
Phil

 Phil

 I just discovered that VCS had supplied a deinstall process, VCS$DEINSTAL.COM
 in sys$manager and I was going to update my base note cause I had made a
 mention with regards to this but you had already replied. 8 pm on a sat night,
 that's amazing

 Mike

Mike,

  8pm on a Saturday night, thats nothing ;-) Its amazing the stuff you
  do when you are bored! 

Cheers,
Phil

Mike,

  When you install the MUP kit, your problem with the editor changing
  the case of the system name on modify will be fixed (although it was
  too late to make the release notes)

  Incidentally, the same problem was there for modifying any of the
  database objects!!

Cheers,
Phil

>  I am glad you agree that the profiles are best managed by the various 
>  development groups, perhaps it would help them understand your problem if you 
>  asked them for scan profiles just like we have been trying to persuade them 
>  to. We have offered to act as a repository for the profiles and ensure that 
>  they work correctly with PCM.

  I didn't actually say quite that. I said you said the profiles are best
  managed by the development groups. The management of these profiles need do
  be done by the Console Manager group. The validation of these profiles should
  come from the various other development groups.

>  I disagree that we are the best people to provide these profiles, we dont 
>  know what you want to scan for, nor do we know how important those events 
>  are, you are the best judge of that in your environment.

  It a lot easier for the user to take out what they don't want (things that
  cause too much noise etc) than to know what to scan for in the first place.

>  Didnt you read the manual as well as the conversion notes, the manual 
>  clearly states that there are only 6 priority levels. I think the upgrade 
>  also asked you to review the output of the conversion process.

  I did in fact read the manual. The first pass however I was concerned with
  VCS conversion information so I referenced those sections. Nowhere did it
  give a warning that installer might want to review the severities because
  they were changed and the conversion executable would assign them based
  on xxx formula. My point was to show that a note was needed for the VCS
  conversion section of your documentation.

>  This is intentional, I am sorry you expect the VMS style of /this/that and 
>  /theother but the product runs on 4 different operating systems and so to 
>  keep maintenance to a minimum we have to pick the lowest common denominator, 
>  now if you pesuade OSF/1 and ULTRIX to implement a cli like DCL on their 
>  operating systems, we can do something for you.

  You can pass qualifiers under OSF/1 similiar to VMS. You just use dash this
  or dash that. There is no need to prompt for options under any platform,
  is there?

>  Phew was that all you could find, I hate to think what you are going to say 
>  when you start **using** the product. Where were you when we did field test, 
>  this is the sort of feedback we could have done with then, however it is all 
>  useful for V2.0. Thanks.

  No I have a number more problems, for example

  o When a console is locked and you have the editor enabled and you move a
    system icon, the locked box remains where it was, I would have expected
    this to be tied to the system and move with it

  o I would like to have setup a system wide CONSOLE$C3 image. I know you
    can use that console$user_defaults logical to redirect but it redirects
    all console files not just the reference for that one file, then there is
    the problem with write access control. I understand you are planning some
    changes here for the next version

  o We just added 6 more consoles to one system (now at 43) and ever since then
    the ENS process is crapping out. Haven't had a chance to look at it yet but
    something about an access violation (using 1.5 ECO1)

>  I didn't actually say quite that. I said you said the profiles are best
>  managed by the development groups. The management of these profiles need do
>  be done by the Console Manager group. The validation of these profiles should
>  come from the various other development groups.

Hmm so what you are saying is that the PCM team (remember that is three of us!!)
trawl through the message catalogues and header files written by other
engineering groups to find the messages we think are of use and generate the
scans and then pass them back to the people that wrote the code so they could
check what we did.

So how many products do we do this for??

Do we do this for each release of each of these products?

I must admit that I do like to spend some time outside Digital and also on rare
occasions get some sleep. What you are asking here would not only ensure I never
had a life outside the office, but would also mean that bug fixes and new
versions of the product would never happen ( including the bugs you have
mentioned in your note).

As Phil said in an earlier reply, I suggest you talk to the product manager and
tell her what you think and see if she can get the people to do the work you
suggest ( or perhaps you would like to volunteer!!).


>  You can pass qualifiers under OSF/1 similiar to VMS. You just use dash this
>  or dash that. There is no need to prompt for options under any platform,
>  is there?

One man's meat is another's poison... I would guess if we did what you asked 
others would have wanted it the other way. Don't hold your breath for this to be
changed as you are the first person who has brought this up as an issue.

> When a console is locked and you have the editor enabled and you move a
> system icon, the locked box remains where it was, I would have expected
> this to be tied to the system and move with it


This is a known problem and is on the C3 developers list of things to do.  

> I would like to have setup a system wide CONSOLE$C3 image. I know you
> can use that console$user_defaults logical to redirect but it redirects
> all console files not just the reference for that one file, then there is
> the problem with write access control. I understand you are planning some
> changes here for the next version

I will add it to the wish list for the C3!

> We just added 6 more consoles to one system (now at 43) and ever since then
> the ENS process is crapping out. Haven't had a chance to look at it yet but
> something about an access violation (using 1.5 ECO1)

We have just announced a MUP see note 2.last. Try this and if you still have a
problem mail us an Export of your database.

Cheers Simon...
 

 Further to the problem I had with the ENS process crashing...

 Two of the 6 new systems were added in lowercase and one of the scan profile
 names was also lowercase. When I changed just these 3 things to uppercase
 and did a console reconfigure, the ENS process came up running no problem.
 Most interesting.

 MIke

 I just recently upgraded one my VMS Console Manager systems to 1-5 MUP1.
 (1.5-004). After upgrading, it started up fine, all 39 consoles were status
 OK. The next day I deleted a system from the configuration and after I
 reconfigured I could not get things working again. Processes are stopping and
 connectivity to some 22 systems is now failing. The completion status for these
 processes is normal-successful so I'm not sure what the problem is. I of
 course tried to restart a number of times, twice things would just hang and I
 could not get the C3 window display to complete the window.

 I tried shutting down the Console Manager and re-instating the previous
 console_cfg.dat but that isn't helping. I wanted to try downgrading to 1.5 ECO1
 but that kit has been removed from the distribution area. Would it be possible
 to get a copy of this kit?

 Mike

Mike,

>> I just recently upgraded one my VMS Console Manager systems to 1-5 MUP1.
>> (1.5-004). After upgrading, it started up fine, all 39 consoles were status
>> OK. The next day I deleted a system from the configuration and after I
>> reconfigured I could not get things working again. Processes are stopping and
>> connectivity to some 22 systems is now failing. The completion status for these
>> processes is normal-successful so I'm not sure what the problem is. I of
>> course tried to restart a number of times, twice things would just hang and I
>> could not get the C3 window display to complete the window.

  Hmm, we knoe that reconfigure is sometimes a little bit flakey, but it shouldnt
  cause these sorts of problems.

  Try defining CONSOLE$DEBUG to deb DAEMON and restarting, when the children exit,
  look in their log files for some kind of reason (the log files will be
  CONSOLE$TMP:CONTROLLER_nn.LOG)

>> I tried shutting down the Console Manager and re-instating the previous
>> console_cfg.dat but that isn't helping. I wanted to try downgrading to 1.5 ECO1
>> but that kit has been removed from the distribution area. Would it be possible
>> to get a copy of this kit?

  When you shut down, make sure that EVERYTING is stopped, that includes connect,
  monitor, status etc. The reason for this is that we keep statistics in a shared
  memory section and if someone is attached, then it doesnt get initialized correctly
  when you restart the daemons, this can cause problems.

  I could give you the ECO1 kit, however, you would then be running a configuration
  which has known NASTY bugs (like missing timestamps in your log files), this would
  also be a configuration I really cannot support.

Cheers,
Phil

...from CONSOLE_NOTIFY_OUTPUT.LOG

$       SET MESSAGE /FACILITY /IDENTIFICATION /SEVERITY /TEXT
$       SET DEFAULT CONSOLE$TMP:
$       SET PROCESS /DUMP
$ RUN CONSOLE$IMAGE:CONSOLE$ENS_DAEMON.EXE
POLYCENTER Console Manager
Event Notification Services Version V1.5-004
Copyright (c) 1994 Digital Equipment Corporation. All Rights Reserved

CONSOLE$ENS_DAEMON: eventport_error Callback
    errno_val : 2147406216
         msg1 : Failed to create Local socket CONSOLE_EVT_ENSC3
         msg2 : Unknown error code: 2147406216
C3 Listener Closed unexpectedly, unable to restart!, exiting.
  SYSTEM       job terminated at 22-DEC-1994 08:30:39.13



Does this mean there is a problem with the console$c3.dat file?


...then a short time later in CONTROLLER_03.LOG

$ !
$ ! Start a Child Controller process, number 3
$ !
$ CHILD :== $CONSOLE$IMAGE:CONSOLE$DAEMON.EXE
$ CHILD
POLYCENTER Console Manager
Console Controller Daemon Version V1.5-004
Copyright (c) 1994 Digital Equipment Corporation. All Rights Reserved

Unable to connect to event port<CR>
Failed to connect to Local listener CONSOLE_EVT_ENS on node <CR>
no such file or directory<CR>
Console port open failure for CORE2
Open failure on LAT terminal (server: LAT186  port: VCS06)
%SYSTEM-F-ABORT, abort<CR>
Console port open failure for CORE3
Open failure on LAT terminal (server: LAT188  port: VCS09)
%SYSTEM-F-ABORT, abort<CR>
Console port open failure for DPSDEV
Open failure on LAT terminal (server: LAT165  port: VCS06)
%SYSTEM-F-ABORT, abort<CR>
Console port open failure for FSHSC2
Open failure on LAT terminal (server: LAT187  port: VCS01)
%SYSTEM-F-ABORT, abort<CR>
Console port open failure for FSHSCA
Open failure on LAT terminal (server: LAT187  port: VCS15)
%SYSTEM-F-ABORT, abort<CR>
.
.
.
Console port open failure for HSJ000
Open failure on LAT terminal (server: LAT187  port: VCS08)
%SYSTEM-F-ABORT, abort<CR>
Bugcheck: Unrecognised primary control code
$ EXIT $STATUS

Mike,

  Can you export your database and mail it to elbrig::sdj

  From your two log excerpts it would seem that ENS failed to
  start because it couldnt create the mailbox that it uses to
  communicate events to the C3 processes running on the system.
  The errno_val looks more like an address than an error number
  to me, so I dont know whats happening here!!! Did you by chance
  have a C3 running when you started up PCM? Or, do you have any
  logicals for ENS before you actually start PCM ($ SHOW LOG *ENS*)

  The second log excerp show the child daemon starting and failing
  to connect to the mailbox that ENS should have created for it (the
  failure is because ENS exited, see the first log).

  The daemon should carry on now, however you will not get any event
  notification until you restart ENS. The daemon now tells you that
  it is unable to connect to the various LAT consoles (the qio completes
  with a status of %SYSTEM-F-ABORT, abort). so the child should continue
  and keep trying to open them.

  Now at some point, the child gets a message from the parent, however,
  this message is not one that it is expecting, or even recognised
  (Bugcheck: Unrecognised primary control code) then the daemon exits.

  Now, looking at the code base, it would appear that the Bugcheck message
  is purely informational, the daemon should continue to execute. Is this
  problem reproducable, what happens if you do:

   $ DEFINE/SYSTEM CONSOLE$DEBUG "DAEMON"

  Then start PCM, are there any more/different messages in the log?

Cheers,
Phil

 
 I noted 2 users running Console images. After reading your comment regarding
 shared memory sections, I stopped these processes.
 - one was running CONSOLE$CONMAN.EXE
 - the other was a subprocess running CONSOLE$C3.EXE

 I restarted and all the CM processes stayed running however there were still
 some 15 systems not reachable. I checked the logs again and there were still
 problems creating the lat ports. I shutdown again and found those 15 lat ports
 were still active. I deleted these lat ports, restarted and all systems are
 now reachable.

 Mike

 Ever since I installed 1.5-MUP1. My action routine is only firing for CMGR
 events. This is on more than 1 machine. I have a single action routine setup
 to fire for all events. Any suggestions as to how to go about fixing this one?

 Mike

Mike,

  Can you post your filter definition which you have set up
  for your events.

Cheers,
Phil

This is the only filter and action presently setup. I've removed that
archive one.

Mike



DELETE_ACTION:
    NAME: Kanata Command Center
END:

ADD_ACTION:
    NAME: Kanata Command Center
    INFO: Send event to Kanata Command Center
    COMMAND: CONSOLE_KAOIOC_ENS
    ACTIVATE_EACH_EVENT_AND_EACH_USER_DATA: Y
    ACTIVATE_ALL_EVENTS_AND_EACH_USER_DATA: N
    ACTIVATE_ALL_EVENTS_AND_ALL_USER_DATA: N
    PASS_NAME: Y
    PASS_CLASS: Y
    PASS_INFO: Y
    PASS_TEXT: Y
    PASS_PRIORITY: Y
    PASS_TIME: Y
    PASS_SYSTEM: Y
    PASS_SUBSYSTEM: N
    PASS_SOURCE: Y
    PASS_USER_DATA: N
END:


DELETE_FILTER:
    NAME: Kanata Command Center
END:

ADD_FILTER:
    NAME: Kanata Command Center
    INFO: 
    INTERVAL: 0
    EVENT_INTERVAL: 0
    FILTER_ALL_EVENTS: Y
    FILTER_ALL_CLASSES: Y
    FILTER_ALL_SYSTEMS: Y
    FILTER_ALL_SUBSYSTEMS: Y
    FILTER_ALL_GROUPS: Y
    FILTER_ALL_PRIORITIES: Y
      ASSIGN_ACTION: Kanata Command Center
            INFO: 
            ANY_HOUR_ANY_DAY: Y
      ASSIGN_ACTION_END:
END:

Mike,

  Any chance of a copy of your action routine CONSOLE_KAOIOC_ENS

Cheers,
Phil

 Maybe this should be on the wish list.

 With VCS, the C3 icon name was "VCS C3 - nodename"
 In Console Manager the icon name is "CONSOLE$C3"

 Having the nodename as part of the icon name was very useful when you have
 multiple C3 displays to deal with. It saves you having to hunt and peck thru
 all the windows to find the particular display you need.

 Mike

    Mike, 
    
        Thanks for your suggestion. We'll put it in the next release.
    
    Dave

 I seem to be having quite a few reliability problems with the new
 Console Manager 1.5-MUP1 kit. A number of machines repeatedly get hung
 up. The Notify and the Console Ctrl nn process go into RWMBX state and
 this hangs further connections. Twice on another machine the ENS process
 died and doing a reconfig crashes the remaining processes. I can't get
 too specific as it's hard to find the time to analyze things and there
 is not just one symptom. Have you other reports in this area?

 Mike

 I've come across another significant difference between VCS and Console
 Manager and I'd be interested in your views with respect to the following.

 Consider the VAX 3000 and VAX 4000 series machines. To be able to halt these
 systems from the console I would normally have the BREAK switch enabled. I
 normally recommended this switch to be set this way as it offers the ability
 to completely manipulate the console remotely. There is no need for a site
 service group to halt your console when that's what you need to do. The 4000s
 have the ability to enable ControlP instead of the break character.

 From a local console

				Break key	Control P character
 VAX 3000			will halt	not applicable
 VAX 4000 ^P disabled		will halt	do nothing
 VAX 4000 ^P enabled		do nothing	will halt
 

 VCS connect

				Default no Break set	/break=CTRL_A_KEY
 VAX 3000			do nothing		^A will halt
 VAX 4000 ^P disabled		do nothing		^A will halt
 VAX 4000 ^P enabled		^P will halt		^P still halts, ^A no


 Console Manager connect

				Default no Break set	/break=CTRL_P
 VAX 3000			do nothing		^P will halt
 VAX 4000 ^P disabled		^P will halt		^P will halt
 VAX 4000 ^P enabled		do nothing		do nothing


 The problem I have is with Console Manager's handling of the console break.
 If I've enabled the ControlP parameter on the console I can no longer halt
 the machine via a console connect. If I disabled the ControlP parameter I
 have to use Control P within console connect and break locally. It's most
 confusing. I now have to change all affected consoles as the do-nothing - 
 do-nothing response is not workable. Do you see this as a problem and will
 changes be forthcoming? 


 Mike

    I see one of perception and terminology. If you set the break key to be
    something other than ctrl-p you *will* be able to send a ctrl-p to
    those systems that require it. I use ctrl-k as it isn't used as a
    terminal line editing key ot anything. So if I type ctrl-k i get asked
    " Do you really want to transmit a break?". If I type ctrl-p then 
    ctrl-p is sent and *no* questions are asked. The fact that the default
    break-key is set to ctrl-p and the terminology used makes things
    confusing. Suddenly customer who were used to be able to typ ctrl-p
    are getting asked if they want to xmit a break!!!
    
    The proposed change is to remove the break key terminology and replace
    it with the term "Halt-key". Ideally this key will be further defineable
    on a per-system basis and defineable such that the key either cases a break
    to be transmitted or is transmitted lierally, i.e., you type ctrl-p an
    ascii ctrl-p is xmitted. Note also instead of asking if a user wants to
    send a break they will be asked:
    
    
    Do you really want to Halt the system?
    
    
    Makes a lot more sense eh?
    
    
    Regs,
       Dan