Easy and Affordable Backup Optimization
Questions about Itanium migration?

Improvements requested, but not yet granted

Even though fewer HP 3000 customers are participating, the Systems Improvement Ballot process to enhance the 3000 received a lot of requests this year. In our printed edition, we recently published a list of HP's responses to the top 11 SIB requests; the vendor regrets to inform its customers that many of the ideas to make the 3000 better are "not a good candidate." This isn't a surprise, when you consider what HP's position is on the 3000: a good computer the vendor recommends leaving behind.

For those who need to stay, however, the list of requested enhancements which follows runs longer than those which had an official HP response from the engineering manager. This more complete list shows the customers who rely on the system are still thinking about how it could be an even more efficient tool. This list also chronicles the maturity of MPE/iX, the 3000's operating environment. Not everyone knows how much the 3000 can do, but those who contributed these requests are aware of the system's potential.

Our thanks to Paul Edwards of Paul Edwards Associates for tracking down these details. Edwards is one of the tireless volunteers working in the OpenMPE organization. For all practical purposes, OpenMPE has become the HP 3000's user group.

A user group advocates improvement, suggesting what the vendor might not be eager to do. While these could look like holes in the 3000's solution, they are really seeds for anyone who takes on the MPE/iX source code, should HP ever license it to a third party.

1.  FTP -- Security protection for netrc files.  Currently, both read and execute access are required to use a netrc file.  This exposes the password to anyone with read capability.  Requesting that FTP be modified to need execute-only access -- similar to UDC and command file access.

2. FTP -- Site chmod.  Enable MPE’s FTP to issue ‘site chmod’ commands. User would be able to correct rwx permissions during an ftp ‘session’. This capability is already supported in hp-ux’s ftp.

3. MPE -- Help text corrections.  Many typos exist in the help subsystem.  Additionally, recent CI enhancments are not included. Requesting a final clean-up of this text.

4. MPE -- Finfo CI function.  Finfo doesn’t report on hfs namespace files correctly (probably a problem with flabelinfo).  Since finfo is closely related to jfinfo and pinfo, it should return status values as well.  Also, finfo should follow symbolic links.

5.  MPE -- Debug.  Repair old/known bug regarding data breakpoints. Very important for support after 2006 (Right, Stan? :-) [A note to Allegro Consultants' Stan Sieler.]

6.  MPE -- Copy.  Copy command can’t copy temporary files to HFS namespace.  This is an hpfcopy() internal bug.

7.  MPE -- Listgroup.  Add ‘format=detail’ option.  Similar to ‘listacct’.

8.  MPE -- Pattern matching bug (impacts ‘listfile’, ‘store’, etc). For store in particular, this could mean some files fail the pattern match and are not stored.  See [HP's] Jeff Vance for details.

9.  MPE -- Repair to call_3 and exec_0 procedures.  Fix the nl and xl so that all call_3, exec_0 procedures validate parms, required for system protection against hackers.

10. MPE -- CI.  CI evaluator operator precedence bug.  See [HP's] Jeff Vance for details.

11. MPE -- CI.  Repair CI error messages with typos or incorrect/inadequate text.

12. MPE -- Implied run.  Repair implied run function to parse parameters correctly.

13. MPE -- Input CI function.  Input;wait does not work in batch.

14. MPE -- listacct.  Repair parmeter parsing and error reporting bugs.

15. MPE -- Purge.  Problem with purge improperly purging files when used in batch.

16. MPE -- Acctinfo/groupinfo CI functions.  Requesting two new CI function be created.  Both would return data currently available via listacct and listgroup but the data would not have to parsed.

17.  Backporting.  (Still) requesting that several recent CI enhancements (like pinfo, CI functions and shutdown) be backported to 7.0 and 6.5.

18. Perl -- Request a filecode for perl (or, opening/reading and looking at the first line, or looking at “.pl” suffix?) that will trigger the CI into automatically running perl scripts.

19. Perl -- It is on invent3k and you can compile it yourself — but the request is to just be able to install it.

20. Perl -- The CI already has been enhanced to accept “#” as an alternative to “:comment “.  Now just use your imagination a little bit and you could almost use the existing, standard Unix-ish “trigger” by starting the script file with “#!/usr/bin/perl”.

21. MPE -- Modify the restore command to allow the onvs= parameter, like in the store command, so specific volume set(s) can be restored. This would be very valuable when all the accounts in the system volume set are needed to be restored after a drive failure. Or, all accounts in a specific user volume set.

22. MPE -- Request is for a function that will return the amount of remaining space in your environment variable stack.

23. Formspec -- Fix the problem with renumbering vplus forms in interactive mode.

24. MPE -- Request the allow command to be persistent.

25. Spooler -- Request spool file % printed.

26. MPE -- Fix character substitution in comments. “/” is now being replaced with spaces.

27. IMAGE -- fix an issue with image b-trees and dbfind. If you do a wildcard find on a master, then try to read thru the found entries,and for each, dbfind detail under the master and read them.  After hitting the detail, the next dbget on the master would get confused and report end-of-chain.

28. MPE -- fix the problem of the mpe logging facility when it overflows/restarts the id# that it generates and assigns to each unique openlog. Seems this id# is simply an integer that is incremented for each openlog, and when it reaches 65,536, the next openlog causes it to restart from the beginning at 1. However, it does not check to see if the process which originally was assigned a number is still connected to logging.  So on a system which has a long-running background job also has a lot of open/close logging events which roll this unique id#, one can end-up with multiple running processes which are logging events using the same id#.