January
2005
net.digest tracks
each months message traffic on the 3000-L mailing list and
comp.sys.hp.mpe Internet newsgroup. Advice offered from the messages
here comes without warranty, so be sure to test before you
implement.
Edited by John Burke
Happy New Year 2005
So much for
the good cheer. The 24-month countdown to the end of HPs
support for MPE/iX is underway. Maybe it is just the holidays (I
write this on New Years Day), but I find myself in a
particularly cantankerous mood. Perhaps it is not the holidays, but
the fact that almost 38 months after the November 2001 HP 3000
discontinuance announcement, HP still has not given any indication if
it will allow MPE to survive as an operating system that can be
supported or enhanced by third parties into the future. All we have
is HPs vague promise to make a decision on the feasibility of
licensing MPE in some form, a decision expected in the second half of
2005. HP has also
fallen well short of fulfilling or even presenting updates to
recent Systems Improvement Ballot (SIB) promises it has made.
For example, over my strenuous objections (contact me personally if
you want the details), an enhancement to MPE network printing was
added to the 2004 SIB. As I predicted, it finished first in the
tactical section. On May 27, 2004, HP presented its response to the
SIB, indicating this enhancement was in plan. Other items
were also supposed to be in plan. Seven months later, there was no
update on the status of these in plan items. [Editor's
Note: After this column was published, HP provided an update on the
SIB items.] Granted, some of the delay is due to Jeff Vances
unfortunate accident, but he was not going to be personally coding
every enhancement. In particular, the MPE network printing
enhancement was not Jeffs responsibility. As of mid-December,
little if anything has been done on this enhancement, as far as I
have been able to determine.
Perhaps it
was just my general holiday bad mood, but as I reviewed the December
3000-L postings, I was struck by how many of them dealt with areas
where HP fell short in making investments in MPE years before
the eroding ecosystem forced HP to
discontinue the HP 3000 (while at the same time IBM was pouring many
millions of dollars into improving the iSeries and OS400). If HP ever
does license MPE/iX to third parties, many of the items in this
months column are low-hanging fruit, just there for the
picking.
I always like
to hear from readers of net.digest and Hidden Value. Even negative
comments are welcome. If you read something on 3000-L and would like
me to elaborate on it, let me know. You can reach me at
john@burke-consulting.com.
From the Obscure
Commands/Options Department
This section
could be subtitled Commands/Options That Never Made It Into A
Manual. Suppose you are using EDITOR (officially named
EDIT/3000) on a 250-character line length file with a termulator that
can be set to display all 250 characters. However, you discover that
EDITOR will only display each line 80 characters at a time. Is there
anything you can do? Thanks go to John Korb for providing the
solution to the posters dilemma: The obscure EDITOR directive
SET NOLNBRK (the default behavior can be set back with SET LNBRK).
In his
posting on 3000-L, Korb commented that he could not remember where he
found out about this option but that it was five or more years
ago. A Google search turned up SET NOLNBRK, along with a number
of other Editor enhancements, in an HP MPE/iX 5.0 Communicator
article entitled Enhancements for Editor A.09.00. This
Communicator has a publication date of January 1995!
Just out of
curiosity, I checked the latest version of the EDIT/3000
manual at docs.hp.com. It has a publication date of are you
ready? August 1980! I guess that is why SET NOLNBRK never made
it into the manual. Unfortunately, this is just one of hundreds of
commands/options that never made it into the appropriate HP 3000
manuals and which are only documented, if at all, in the
Communicators. It is also another example of how HP skimped on its
investment in MPE in the 1990s and how that lack of investment
created challenges that will task homesteaders and any organizations
attempting to support/enhance MPE beyond 2006.
Want another
example? With the G3 release of ALLBASE/SQL and IMAGE/SQL, the
supported SQL syntax was enhanced to include the following string
manipulation functions: UPPER, LOWER, POSITION, INSTR, TRIM, LTRIM
and RTRIM. Where do you have to go to find this? The MPE/iX 6.0
Communicator, of course.
gnu, Apache, Samba,
Java, Perl, Sendmail, etc.
Every month
3000-L contains postings about one or more of the above; usually
along the lines of How do I install
? or How
do I do [substitute some relatively simple task]?
or Why isnt this working? Why the confusion? In
part, this is because HP brought none of these systems to the HP
3000, and so the software has always suffered from the
not-invented-here syndrome; i.e., available, but not really a part of
MPE. Documentation on this software is meager; the systems are
usually one or two releases behind the current general release; they
are not performance-tuned for MPE; and the best support vehicle is
3000-L.
In spite of
this lack of attention, these systems are the most important to come
to MPE since IMAGE/SQL in the early 1990s. They also had a lot to do
with keeping MPE relevant. [A case can be made that ODBC support was
equally important; but note that HP did not develop it either
third parties did.]
These systems
became available only because non-HP employees, or HP employees
working on their own time, did all the work. For example, gnu was
ported by Mark Klein and is the mother of all others on the list.
Mark Bixby ported Apache, Perl and Sendmail before he became an HP
employee. HP employee Lars Appel ported Samba on his own time, and
Mike Yawn did Java for the HP 3000, mostly on his own time in the
beginning. Contrast this with IBMs iSeries, where Apache and
Java are key, indispensable components.
Gee, I Wonder When
This STORE Tape Was Created?
It is
probably more and more likely that, as the years pass by, you will
discover a STORE tape and wonder when it was created. Therefore it is
a good idea to review how to do this. I started out writing how
to easily do this, but realized there is nothing easy about it
since it is not well-documented and if you just want the
creation date, you have to do a bit of a kludge to get it. Why not
something better?
It turns out
the ;LISTDIR option of RESTORE is the best you can do. But if you do
not want a list of all the files on the tape, you need to feed the
command the name of some dummy, non-existent file. ;LISTDIR will also
display the command used to create the tape. By the way, this only
works with NMSTORE tapes. For example, when ;LISTDIR is used on a
SYSDUMP tape that also stored files, you get something like this
(note that even though you are using the RESTORE command, if it
contains the ;LISTDIR option, nothing is actually
restored):
:restore
*t;dummy;listdir
>>
TURBO-STORE/RESTORE VERSION C.65.19 B5151AA <<
RESTORE *t;dummy;LISTDIR
FRI, DEC 31,
2004, 3:22 PM
RESTORE SKIPPING SLT
IN PROGRESS ON LDEV 7
MPE/iX MEDIA DIRECTORY
MEDIA NAME
: STORE/RESTORE-HP/3000.MPEXL
MEDIA VERSION
: MPE/iX 08.50 FIXED ASCII
MEDIA NUMBER : 1
MEDIA CREATION DATE
WED, MAY 7, 2003,
7:06 AM
SYSGEN
^SLTZDUMP.INDIRECT;*SYSGTAPE;LDEV=7;
REELNUM=1;SLTDATE=52863;TIME=117839624
MEDIA CREATED WITH
THE FOLLOWING OPTIONS
OPTION DIRECTORY
OPTION ONVS
Doctor, it
hurts when I do this.
Then dont
do that.
Let me offer
another example of how lack of investment continues to create
problems. A user is connected to an MPE/iX 7.5 system (with current
patches) via telnet and is running grep from a CI script. BREAK is
hit, but the colon prompt is not returned and the session is hung.
Nothing short of a reboot will cure the problem. It turns out it is
not a Posix issue or grep issue per se, but a problem between BREAK
handling and CI variable accesses. This dates back to the time when
CI variables where introduced. From the Service Report, circa
1998:
Problem
Text: A session hang can occur if the Break key is hit in a very
small timing window, when processes are running under the
CI.
Cause
Text: A deadlock can occur in this timing window involving the CI
process and one of its child processes. The deadlock is between the
CI Var Table lock and the Terminal PACB lock.
Temporary Solution: Disabling BREAK for sessions can be
used as a workaround.
Fix
Text: Since the problem occurs very rarely and a fix would mean a
larger number of complex code changes, there are currently no plans
to fix this.
In other
words, hard cheese. HP said they can fix it, but do not want to make
the investment. Disabling BREAK is not a particularly appealing
option for most people, yet the possibility of a hung session can be
even worse when the only recourse is a reboot.
During the
1990s, hung VT sessions were ongoing nightmares for IT Managers. If
you were an IT Manager during this period, as I was, then you
probably remember this well; yet HP never invested in a foolproof way
to terminate a hung session without a reboot. If it wanted to tout
(and sell) the robustness of MPE/iX, should this not have been a high
priority?
Short
Cuts
At HP
World 2004, SIGMPE formally requested that HP back-port all
appropriate enhancements/fixes to all the supported OS
releases (6.5, 7.0 and 7.5). There is still no word whether this will
happen. Consider, for example, user-written CI functions. This is an
enhancement that has been in the works for years; however, it is not
available for MPE/iX 6.5 or MPE/iX 7.0.
Since
the introduction of User Defined Commands (UDCs), people having been
replacing MPE commands with UDCs of the same name.
Perhaps it is to prevent use of a particular command or subsystem
(PASSWORD, Query, etc.) or perhaps it is to provide additional
functionality (such as logging of command usage). Be careful though,
as Stan Sieler noted, because :EDITOR (and anything calling the
COMMAND, not HPCICOMMAND, intrinsic) wont see a UDC. It
would have been nice if HP had updated all subsystems to use
HPCICOMMAND.
If I have two successive PowerPatches for an OS version, can
they both be loaded into @.INSTALL.SYS and AUTOPAT run for both of
them, or do they have to be run separately in succession? You
do not need to do either. PowerPatches are cumulative. You only need
to install the most recent. One of the really great enhancements to
MPE/iX was the combination of Patch/iX and Stage/iX. The only
downtime required to apply a patch, or patches, is the downtime
necessary for a shutdown/reboot. Even better, if you need to back out
a patch, it can be done with another shutdown/reboot sequence. Of
course, you still cannot stage a PowerPatch (hours instead of
minutes), even though HP was supposedly working on making this
possible.
Suppose you want to know all permanent files opened by a particular
job or session. This is not possible with standard MPE/iX. You either
must purchase a third party tool such as MPEX or purchase Glance/iX
from HP to do something that any developer/administrator wants/needs
to frequently do.
STORE/RESTORE is a reasonably good product. Once the NM spooler was
implemented, we were able to use it to store and restore spoolfiles.
However, even though all the characteristics of the spoolfile are
stored, there is no way to determine what is on a tape without
actually restoring the spoolfiles.
Copyright The
3000 NewsWire. All rights reserved.
|