I upgraded from MPE 4.0 to 5.0 two weeks ago. The actual upgrade process
was painless, and worked as advertised. However, the following post-upgrade
"gotchas" soon surfaced:
1) TurboStore ;ONLINE conflict with Omnidex. This is actually an old, patched
4.0 bug that resurfaced. TurboStore will open the Omnidex root file with
long-mapped access. If an Omnidex program tries to open the same Omnidex root
file while TurboStore still has the file, Omnidex attempts short-mapped access
which fails because the file is already open long-mapped. Your Omnidex program
will die with:
The mapping options for the file are not correct.
(File open error -462)
The workaround is to prevent TurboStore from backing up your Omnidex root
files, either via fileset exclusions, or by using Datadex to open your
Omnidex databases in READ-ONLY mode 5, which STUPIDLY (are you reading this
DISC?) opens the Omnidex root file in update mode which prevents it from being
:STORE-ed. This is obviously undesirable if you have a disk media failure and
need to restore your entire databases, including the Omnidex root file. You
would be forced to re-install Omnidex.
A bona-fide fix is coming from DISC with the "3.3 patch" release of Omnidex,
no date available yet. If you have Omnidex and TurboStore ;ONLINE, I urge you
to call Omnidex and inquire about this release. The more people that complain,
perhaps the faster it will be released.
2) A NASTY ODBC G0 security bug. See SR 5003-216218 for the gruesome details.
This SR is on the SupportLine web site for all to see, so my conscience is
clear about posting this to Usenet. A patch is available (and is on its way
to me in the mail) where you must upgrade to Allbase G1. IMPORTANT NOTE: this
G1 patch does not support SQL access to IMAGE databases, which will not be
supported by G1 until the Express-3 release in September. The old ODBC F0 is
still supported and does not have a security problem. You only expose
yourself if you start the new G0 listener via "ANSTART ARPA".
I was sufficiently upset by this huge security hole (how could HP possibly
ship the 5.0 Push with this known bug lurking around!), that I notified
[log in to unmask] to warn them that I would eventually post a warning to
Usenet about it. Nobody ever acknowledged my e-mail, and the SR remains
available for public viewing.
3) EDITOR.PUB.SYS use of the ;INFO string. We had some truly ancient PARM=16
procedures that were examining the ;INFO string for local functionality.
EDITOR now uses the ;INFO string to pass commands independent of the PARM=16
procedures.
4) Our ancient CM copy of IDLEJOB would refuse to shut down. Fixed by
upgrading IDLEJOB to what's on the last Interex CSL tape.
5) Miscellaneous local programs were expecting uppercase CIERROR messages. No
big deal to look for the mixed-case 5.0 versions.
6) A number of COBOL programs are dying due to not conforming to the WRITE vs.
REWRITE standard as explained in the 5.0 Communicator. Use the runtime fix,
or re-compile.
7) At least one ancient CM program crossed over a maximum MAXDATA into stack
overflow. We may be forced to migrate this one over to NM.
This system is a mission-critical 980/100 in full production mode. It's been
rather well-exercised during the past two weeks of 5.0. No system failures
or critical "show-stopping" problems so far.
If anybody has any urgent questions about any of these issues, you should
probably e-mail me since my newsfeed through which I receive comp.sys.hp.mpe
is overloaded and tends to run about 5 days slow.
--
Mark Bixby E-mail: [log in to unmask]
Coast Community College Dist. Web: http://www.cccd.edu/~markb/
District Information Services 1370 Adams Ave., Costa Mesa, CA, USA 92626-5429
Technical Support +1 714 432-5865 x7064
"You can tune a file system, but you can't tune a fish." - tunefs(1M)
|
