It may have been an aberration, but last month the number
of off-topic postings to HP3000-L, particularly rants, was way down and the
technical content was way up. On the off-topic front, Gavin Scott posted this about the Unix Haters Handbook: “This classic
work (which has been out of print for some time) is now available for free as a
single 3.5 MB PDF file from:
http://research.microsoft.com/~daniel/unix-haters.html. It is a humorous and
surprisingly useful guide to the wonders of Unix operating systems.” Those of
you considering a migration to HP-UX might want to check it out. April also saw
the 50th anniversary of the publication of Watson and Crick's seminal paper on
the identification of DNA as the molecule that carries the information of life,
the source of essentially all heredity. On a more sobering note, April saw the
death of both Adam Osborne, pioneer of the portable PC and Edgar Codd, database
pioneer and recipient of the A.M. Turning award (1981).
I always like to hear from readers of net.digest and Hidden Value. Even negative comments are welcome. If you think I’m full of it or goofed, or a horse's behind, let me know. If something from these columns helped you, let me know. If you’ve got an idea for something you think I missed, let me know. If you spot something on HP3000-L and would like someone to elaborate on what was discussed, let me know. Are you seeing a pattern here? You can reach me at john@burke-consulting.com.
News of its death was
premature
This from Denys Beauchemin,
of HICOMP and a member of the Interex Board of Directors: "HP has just
announced the release of the latest generation DDS drive, the DAT72,
contradicting its announcement that DDS was dead just a couple of years ago. The last version of DDS was DDS-4 initially
released 4 years ago. The DDS-5 drive seems to have the same throughput but
somewhat higher data density compared to the DDS-4. The capacity is 36GB
native, 72GB with 2:1 compression. The
transfer rate remains the same as DDS-4.
DAT72 uses a longer tape, 170 meters VS 150 meters for DDS-4, in order
to accommodate some of the extra storage.
They are also presenting a roadmap depicting the 6th and 7th generation
of DDS drive in 2005 and 2007 respectively with rapidly increasing capacities if
not throughput."
Christian
Lheureux, of Appic R.H. and a member of the OpenMPE Board of Directors put
together a DDS compatibility matrix that shows what each type of DDS drive can
read/write. If you email him he will send you a copy, or you can get it at
http://www.burke-consulting.com/DDS_Comp_Matrix_2003_04.xls
Ah, what might have been?
"Has anyone
done any work at possibly porting PHP to MPE?" This question was asked
recently on HP3000-L. The answer is actually yes, but unfortunately most of the
significant work was done around the time HP decided it did not want MPE in its
future and news of the development effort got lost in the resulting noise and
turmoil. Campbell Feathers of the Australian company CANNEX (www.cannex.com.au)
brought everyone up to date:
"It's not
that difficult. See http://invent3k.external.hp.com/~MGR.FETHERS/. This is now
a fairly old version of PHP and Apache, but the same instructions can be used
for porting a more recent version. It does need some attention from a porting guru,
but it works. Due to (1) lack of time and (2) lack of demand, I haven't kept
the invent3k version up to date. If requested, I could probably make a more
recent version available for download.
"Compiled
into Apache, performance has been more than adequate on our N4000 for our
external customers. Obviously, the CGI (i.e. standalone) version is totally
unsuitable for serving web pages due to MPE program load time. The TurboIMAGE
function library that we created has turned out to be very useful. PHP &
IMAGE really complement each other well. We now have about 74000 lines of PHP
code, used for mission critical, highly interactive data retrieval, and also
used for some complex iterative annuity calculations."
I only have
limited experience with PHP and Apache but came away very impressed. Coupled
with Feathers’ TurboIMAGE extensions, we could have had a real killer tool for
the HP 3000. If only…
This is kind of geeky, but neat. It is something I could have used a year or two ago when I had a situation just like this poster: "I have been asked to set up a News/Weather etc capability for our Intranet. Access to the Intranet is through a gateway but is restricted for the users so I am looking at using RSS feeds with PHP to populate a MySQL database with items that the users can view. I am having difficulty finding much information on how to do this. Does anyone know of any good forums or groups where I can ask the appropriate questions?"
Mark Wonsil
supplied the following response: Here's a PHP module that consumes RSS feeds,
http://magpierss.sourceforge.net/. For those who are asking, "What in the
hell is an RSS feed?”, check out http://backend.userland.com/rss.
While Dave Wilde,
head of vCSY, reiterated again at the recent HP e3000 Solutions Symposium that
HP would continue to supply high quality support for the HP 3000 until
end-of-support 12/31/2003, the complaints of poor support are already starting
to roll in. There are still many good HP 3000 support people at HP, but we all
live in fear that their jobs are at risk every day. And, we live in fear of the
cost of "high quality" HP support in 2006. Consider these recent
support complaint examples:
We placed a call
to HPQ (24x7 4-hour response), got a call ID and then waited for 2 1/2 hrs for
a call back only to be told we will have to wait for another engineer call us
back "shortly". "Shortly" turned out to be an additional 2
1/2 hrs. Fortunately Rene Woc of Adager was able to tell us in the meantime
that we needed a specific patch to fix our repack problem. By the time we got
the call back we were already up and running and repacking data. Oh, and the
engineer who finally called back was not the most knowledgeable apple in the
cart but did finally agree with Rene's fix.
In my opinion,
staffing at the Response Center for MPE related questions is at frighteningly
low levels.
Since the middle
of 2002 I have tried to use HP support less and less. You can tell the
difference between the old "award winning service days" and the
present.
A customer of
mine had problems getting sendmail going on a brand-new N4000 on MPE/iX 7.5. I
placed a call to the HPRC and was asked what type of system we had. I told her
it was an HP3000, and was connected to printer support.
Are the days of
"what's an [hp3000|MPE] system?" back? Unfortunately they are.
There is
something wrong when users have to be trained on how to work with support
personnel, instead of support personnel being trained on how to work with
users.
I believe that
there are now more HP3000-knowledgeable support people/entities in the
third-party arena than there are available from the manufacturer. If I am
looking for answers to some HP 3000 issues, I do not contact HP I come to
HP300-L or a third party support organization. It's just a fact that you're now
more likely to get good support from third-party vendors.
This has been the
case on the hardware side for many years. In the San Francisco Bay Area you can
usually find your ex-HP CE working at your favorite 3rd party hardware support
vendor.
By the way, it
was "third parties" who found the problem [originally referred to
above], determined how to detect if you had it, and reported it to HP.
In case you missed it, a
little gotcha with the CI function “finfo”
You may not
realize it, but your MPE system already has a number of symbolic links. One
that almost everyone has is /etc/resolv.conf, which points to RESLVCNF.NET.SYS.
Many people have taken to using symbolic links in sometimes very creative ways.
Unfortunately (my opinion), it turns out that the CI function "finfo"
not only does not follow symbolic links as you might expect, but, as someone
rather graphically pointed out, "blows chunks" when handed a symbolic
link. According to Jeff Vance, it would be a one-word patch to tell
"finfo" to follow symbolic links. Putting my co-Chair of SIGMPE hat
on, please let me know if this is something SIGMPE should pursue.
While I’m on the subject of “finfo”, let me point out another gotcha. This one derives from MPE’s sophisticated file management system. All you can ever say with certainty about the location of a file is the volume set it resides on. The file label and extents can physically all reside on different disk drives. Finfo(“filename”, “ldev”) only gives you the location of the file label. “LISTFILE filename,3” will also only show the location of the file label. MPE requires that certain system files be on LDEV 1. Unfortunately, there is no simple way to determine if a file, including its file label and file extents, resides wholly on a particular disk drive. The DISPLAYEXTENTS command of FSCHECK will show the location of all extents, but it is difficult to interpret. One way to ensure a file including its file label and all extents resides on a particular disk drive is to store it to disk with STORE and then RESTORE it with the “;DEV=#” parameter.
I did. Recently Jeff Vance provided a description: The PAUSE command is implemented by polling
the JMAT (table that the SHOWJOB command scans), not based on receiving a
signal from the terminating job, or some other technique. The JMAT polling
algorithm starts out with short sleeps before re-scanning the JMAT, but each
subsequent JMAT poll occurs after a longer and longer sleep interval. (Note:
the sleep interval is reset when the job ID or job state changes. Assuming you
are pausing for a single job then only the state could change.) The longer the
PAUSE command is "sleeping" for a particular job (or session), the
longer each real sleep interval will be.