[log in to unmask] wrote:
>

> SIG SysMan 2000 Ballot

> [   ]    item #1:  CONSOLE output to multiple destinations
> item description:
> :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.
>
> [   ]      Item #2: System log output to multiple destinations
>  item description:
> 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).
>
> HP could provide the 'system log output to multiple destinations' request
> by a simple extension of the 'displaylog' command within 'logtool' which
> currently displays I/O and diagnostic log entries as they are logged into
> the log file (A 'stand alone' command would also be welcomed and possibly
> preferred).
>
> [  3]   item #3:  Kernel incorporation of SysLogD
> item description:
> If SysLogD would [optionally] listen for another socket connection for
> output of messages, you could telnet into this port and have a "Remote
> Console" of sorts that monitors/captures these messages. Or write a
> program that connects and processes these messages such as listing for UPS
> messages, reply requests, session/job logons. You could connect to listen
> to your console from anyplace on the Internet.  Even have multiple
> connections so you and your other sysadmins or a processing program can
> view the console.
>
> [   ]   item #4: "Can't initiate new sessions now"
> item description:
> Change the logon process to be more logical.
>
> [   ]   item #5:  Initial connection text
> item description:
> Required by many companies - the government in particular.
>
> [   ]   item #6:  "Process-local" CI variables
> item description:
> The original specifications requested system-level CI variables - with a
> security matrix - as well as process-local variables.  "Process-local"
> variables are intended to have a larger scope than current CI variables
> but less than the proposed System-level variables.  HP is indicating that
> process-local variables can leverage much of the work already done for
> existing CI variables and so is "easier" to do.
>
> [  3]    item #7:  System-level user-defined CI variable
> item description:
> Again, the original specification requested system-level CI variables and
> process-local variables.  This ballot item will help HP gauge the need for
> system-level variables.
>
> [  2]   item #8:  Shutdown mechanism
> item description:
> This "mechanism" would probably be in the form of a command or a script
> and is envisioned to be similar to the "SysStart" command file.
>
> [   ]   item # 9:  Integrate MPE with UPS
> item description:
> This request is tightly coupled with the (above) shutdown mechanism.
> Again, the shutdown mechanism and UPS integration are being split to give
> HP a better idea of the user community's true needs.
>
> [   ]   item #10: "MPEXL_SYSTEM_VOLUME_SET" variable
>
> [   ]   item# 11:  Certification
> item description:
> Rework the certification exam to accurately assess a candidate's skills.
> The current exam is too vague and/or inaccurate to be useful.
> Additionally, we're requesting the exam be kept up-to-date as MPE systems
> advance.
>
> [   ]   item # 12:  Enhance NMMGR
> item description:
> This new enhancement request is asking for a way to declare the minimum
> and maximum number of servers permanently.  Currently, this information
> can be declared dynamically (i.e., "NSCONTROL SERVER = VTSERVER, 80,500")
> and is still the preferred method for making changes on the fly.  If a
> server is defined in NMMGR, and no associated (superseding) declaration is
> made at network start-up time, then the values in NMMGR would be used.
>
> [   2   item# 13: INETD services priorities.
> item description:
> Currently, all services declared in Services.Net (/etc/services) inherit
> INETD's job queue priority.  The new enhancement would provide more
> granular management.
>
> [   ]   item # 14:  Remsh-d
> item description:
> This enhancement is needed to allow other OS's "standard" access to MPE
> systems.  Of particular interest is the notion of a "light weight" logon
> plus having STDOUT routed to the initiator.  Additionally, this request is
> specifically to port remsh-d - not all of the "r" daemons.
>
> [   ]   item# 15:  Enhance NEWACCT, etc.
> item description:
> This request is asking to introduce the concept of a default location for
> an account.  The default, as envisioned, could be regarded as a
> "suggestion" when creating new groups in an account - that is, it could be
> easily overridden by a ";homevs=" and ";onvs=".  Note the request will not
> change the existing behavior of "mkdir".
>
> [   ]   item #16:  Centronics printing.
> item description:
> This request is on the ballot due to the great outcry from the user base
> about the state of printing on the 3000.  While it is related to the next
> ballot item, enabling centronics printing is new to MPE.
>
> [   ]   item #17:  CIPER protocols.
> item description:
> Part 2 to the state of printing on the 3000.  Currently, the CIPER
> protocols are tightly coupled to the soon-to-be-obsolete HP-IB drivers.
> We're asking HP to retain and update the CIPER protocols for MPE.
>
> Thank you very much for your input!


Cheers,

John Dunlop

E-mail : [log in to unmask]       "If at first you don't succeed...
Web : http://www.hp3000links.com       Don't take up sky-diving !"
"All your HP3000 resources on the Net"