The console idea is really nice but may already have been address by the new
web console product that HP announced recently.  I'm just not certain if it
supports multiple connections.

Carl McNamee
Systems Administrator
Billing Concepts

> -----Original Message-----
> From: Donna Garverick [mailto:[log in to unmask]]
> Sent: Monday, August 02, 1999 12:24 PM
> To: hp3000-l; sig sysman
> Cc: saurabh
> Subject: Re: [SYSMAN:21] hpworld sig sysman meeting
>
>
> i received the following suggestions for the upcoming sysman meeting.
> they're quite intruiging (imo).  any comments?  opinions?
>          - d
>
>
> > Some enhancement suggestions for SIGSYSMAN's consideration:
> >
> > 1) CONSOLE output to multiple destinations
> >
> >    :CONSOLE  [ldevlist]
> >
> > where ldevlist    ::=   [- | +] <destination>     [, ldevlist]
> >       destination ::=   <ldev> | <ME or "*"> | <filename>
> >
> > Every console message goes to all destinations specified on
> the ldevlist.
> > Only one "filename" may be specified.  Perhaps we restrict it to be
> > a message file (and that file is written to in non-blocking mode!).
> >
> > CONSOLE -23  takes LDEV 23 off the list.
> > CONSOLE 23   changes the list to be just "23"
> > CONSOLE +23  appends 23 to the list (if it was not there already)
> > CONSOLE      displays the list
> >
> > A possible alternative for "filename" is:
> >
> >     <PORT ###>
> >
> > where ### is an IP port.
> >
> > The <filename> (if message file) and the PORT both provide powerful
> > means for easily implementing console message handling utilities.
>
> to me -- this just boggles the mind!  (in a good way :-)
>
> > 2) kernel support for SYSLOG
> >
> >    (ask Mark Bixby?)
> >
> > 3) system log output to multiple destinations, or at least
> one extra:
> >
> >    If LOGMSG.PUB.SYS exists, and is a message file, then the
> >    system will open it at SWITCHLOG time (if it wasn't already
> >    open) and write (in non-blocking mode) a copy of every log
> >    record to it.
> >
> >    This would preserve the existing non-MSG LOG#### structure, and
> >    would provide for the ability to have an efficient real-time log
> >    monitoring mechanism of the user's choice.
> >
> >    The "SWITCHLOG" note above implies that you wouldn't have to
> >    reboot the machine to get the feature started...just
> build a message
> >    file called LOGMSG.PUB.SYS and do a SWITCHLOG.
> >
> >    The FWRITE to LOGMSG would be of the "non-blocking"
> type, which means
> >    if the message file fills up, it won't impeded the logging system
> >    (instead, messages going to LOGMSG will be lost until
> someone starts
> >    reading messages out of it).
>
> given the amount of discussion 'we' have had lately regarding
> system logging
> both of these suggestions seem quite good....
>
> so...any thoughts?               - d (thanks stan!)
>
> --
> Donna Garverick     Sr. System Programmer
> 925-210-6631        [log in to unmask]
>
> >>>MY opinions, not Longs Drug Stores'<<<
>
>