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'<<<