Couldn't help but notice that the form came "pre" filled in, a little help
for the weak of mind? : ).

John "Danger" Skelton

-----Original Message-----
From: Victor Pierce [mailto:[log in to unmask]]
Sent: Monday, April 24, 2000 10:37 AM
To: [log in to unmask]
Subject: Re: System Management Enhancement Ballot


Larry LaForge
04/24/00 07:44 AM


        To:     Victor Pierce/Milford/Himco@Himco
        cc:
        Subject:        [HP3000-L] System Management Enhancement Ballot


----- Forwarded by Larry LaForge/Milford/Himco on 04/24/00 07:44 AM -----


[log in to unmask]
Sent by: HP-3000 Systems Discussion <[log in to unmask]>
04/21/00 10:34 PM
Please respond to advocacy


        To:     [log in to unmask]
        cc:
        Subject:        [HP3000-L] System Management Enhancement Ballot


Hello HP 3000 Users,

    Below is a list of 17 HP 3000 System Management related enhancement
requests, developed by Interex's SIG SysMan. These enhancement requests
have not yet been submitted to HP.  We are asking for your assistance in
prioritizing this list. Your top priorities will be submitted to HP via
SIG SysMan and included on the Interex 2000 System Improvement Ballot.

    In order to prioritize this list, we are asking you to vote for your
enhancement choices. You have 10 votes to spend on 17 items. You  many use
all 10 on one item, or divide them as you wish. Your vote total may not
exceed 10. You may not cast negative votes.

   Send us your priorities by replying to this email and placing your
votes, as indicated above, in the brackets [ ] beside each ballot item.
Ballots that do not sum to 10 will be excluded from the tally.

Thank you for your input.
Sincerely,
SIG SysMan leadership
--------------------------------------------------------------------------
--------------------------------------------------------------------------

SIG SysMan 2000 Ballot


**  NOTE:  Ballot items 1, 2 and 3 have significant overlap.  While SIG
SysMan believes ballot item #3 (SysLogD) is a "more elegant" solution, HP
wants a clear indication from the users about how to solve the "busy
console" problem.  Please vote as you see fit.

[   ]    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).

[   ]   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.

[  3 ]   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.

[   ]    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.

[   ]   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.

[ 3  ]   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".

[  2 ]   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.

[ 2  ]   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!