August saw HPWorld 2003 come and go as the last gathering of MPE-IMAGE aficionados prior to the end of sales for the HP e3000 on October 31, 2003. By most measures, HPWorld 2003 was a huge success. Ron Evans, Executive Director of Interex, reported after the conference that attendance was approximately 8400. It is my understanding this was significantly more than was budgeted for, meaning the conference was almost certainly a big financial success.
During the conference, the rumor mill had the attendance of people interested in MPE-IMAGE pegged at only 80 or so. This seemed reasonable, if extremely disappointing, given that no MPE track session had more that fifty people, including HP employees, and only a couple had even forty. However, Ron Evans later reported that 571 attendees had checked MPE on their registrations. We can only speculate where all these people were during the conference since they clearly did not attend any MPE sessions. Perhaps they were checking out HP-UX or .NET sessions? We will probably never know for sure. The consensus, however, among all the people I talked with was that the majority of HP e3000 users are sitting on their hands for the time being and are not actively involved in any transition. The attendance information came out in a thread that basically questioned the relevance of HPWorld, and by extension Interex, to HP e3000 users with some people proposing a conference separate from Interex. Obviously no conclusions were reached, but it is something I will be monitoring closely.
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.
Even
more on SCSI is SCSI
At HPWorld 2003,
HP’s Jim Hawkins (MPE/iX I/O Team Lead) gave a talk titled “Future Proofing
Your HP e3000 Mass Storage.” Hawkins indicated his slides would be posted on
jazz at some point; however, as of this writing, they have not, nor have they
been posted along with many other slide sets at the HPWorld web site.
One rumor Hawkins
confirmed involved Ultrium (LTO) tape drives. Hawkins’ team tested them with
Turbostore and 3rd party backup products. Turbostore performance was
disappointing; however, the performance of 3rd party backup products
with LTO was very good. HP has no plans to modify Turbostore to work with LTO
drives. If LTO support is of interest, and especially if you are already using
a 3rd party backup utility, I suggest you contact your backup vendor
for further information.
Hawkins reported
that HP is working on disk support beyond 146 GB, device driver “hardening” and
SCSI “pass through” functions (note this is not the ”stub” for emulator
support). It may possibly investigate next generation FC arrays, DDS5, Ultrium
460, future SCSI JBOD and future FC JBOD. HP has no plans to investigate Ultra
320 SCSI (would require a new driver) or future FC HBAs.
There was a
lengthy discussion during and after Hawkins talk about the firmware that HP
loads on all HP-branded disk drives. If you have been following the SCSI is
SCSI debate, you know that there has been considerable controversy surrounding
the purpose and value of this firmware. If nothing else, the debate has
persuaded HP to describe for the first time what it views as the value added
nature of this firmware. It turns out that much of the confusion has stemmed
from a decision HP made to have the firmware change the manufacturer field to
“HP” but not to change the model number reported by the drive (this is what MPE
interrogates) to indicate the HP model number. Thus we all see a model string,
usually indicating Seagate as the manufacturer, and assume (naturally) that we
can buy the named Seagate drive and it will be interchangeable with the HP
model (not to mention considerably less expensive). HP makes a pretty good case
that, particularly on high-end systems, the HP firmware does add value and
helps prevent “bad things” from happening. On low-end systems with the SE
interface the situation is much less clear. It is still likely true though that
on those systems, using generic drives will work OK.
Someone suggested
that perhaps at some point, certainly by end of support for the HP e3000, HP
should make the disk drive firmware available and installable for both
homesteaders and for those who have not completed their transition to another
platform. This opens up an entire new source of parts for users trying to keep
their HP e3000s running. The response from vCSY, both at Hawkins’s session and
in later conversations, was mostly positive. As Co-Chair of SIGMPE, I promise
to keep this issue out in front.
Even experienced
users of MPE are sometimes confused about the forward/backward compatibility
issue. Jerry Fochtman, winner of the 2003 Interex Hall of Fame award, provided
the following explanation:
"HP only
strived to provide forward compatibility. There actually are a number of things
that aren't backward compatible. Backward compatibility is a 'it depends'
situation. For example, the process stack markers changed at one point,
creating potential problems for those that had developed programs to look in
the stack to obtain PARM values (which didn't require PM code) before there was
an intrinsic to obtain this information. Also, a number of tables or non-public
routines changed over the years, which affected 3rd party tools. Most 3rd party
tools do OS version checks to determine how to handle the differences.
"So there's
been a whole host of things that have evolved and to HP's credit, forward
compatibility has been quite seamless over the years. Indeed, code I wrote
almost 30 years ago will still compile and run today without any changes. Even
programs compiled and prepared 30 years ago will run on the latest HP e3000s.
Certainly a testament to HP and their efforts at providing a stable business
computing environment."
The following question was posted on HP3000-L: I’ve been working with creating processes and GETPROCINFO. GETPROCINFO works with a 32-bit PIN number. I understand a PIN to be a bit like a process ID (PID) on UNIX. But when I look at PROCINFO, it uses a 16-bit PIN. To further confuse me, this PIN is documented as not being compatible with GETPROCINFO’s PIN. So, are there two PIN numbers for a process?
Michael Anderson,
Gavin Scott, Duane Percox, Jeff Vance and Stan Sieler all contributed to the
following summarized answer:
There is the
original, externally visible MPE V 16-bit Process Identification Number (PIN)
and an internal 64-bit Process ID number (PID -- not to be confused with a
Protection ID, PID). Also, there is the POSIX PID as shown by the POSIX shell's
“ps” command.
The internal PID
is 64 bits containing a 16-bit machine number (always 0), a 16 bit PIN and
followed by a 32 bit re-use count. It is unique during one bootup of the
system. The external POSIX PID is 32 bits containing a 16-bit re-use count
followed by a 16-bit PIN. The external PIN is a unique 16-bit number for the
duration of the process and it's children. PIN's are re-used by the system and
hence are not unique over time, but they are unique across a single snapshot.
If you are on 7.0 or later, try ":help pinfo" and scroll down to the
PIN related items. Also, check out the 7.0 Communicator article at
http://jazz.external.hp.com/papers/Communicator/7.0/exp1/ci_enhancements.html.
There is really only one kind of PIN. Prior to MPE/iX 7.0, the maximum PIN was about 8191 (and smaller on some older releases). With 7.0, very large systems can enable the BIGPIN option, increasing the limit to 12000 PINs. Thus, a PIN can be still represented in 16 bits. As for 16-bit vs. 32-bit, on MPE V, intrinsics that accepted PIN parameters used 16 bits for the parameters. On MPE/iX, the architects wanted to look forward to the possibility of having more than 32767 processes. (During the original design of HPE, which became MPE XL / MPE/iX, negative values had a special meaning. That feature was, however, dropped.) The possibility of having a larger number of processes someday led the architects to use 32-bits to hold PINs in all new (i.e., native mode) data structures.
However, for
source-code compatibility reasons, all native mode intrinsics that had the same
name as their CM counterparts had to keep their parameter size the same where
possible (CREATEPROCESS, SEARCH, and MYCOMMAND are the three most common
intrinsics whose parameters had to change).
New intrinsics (e.g., AIFPROCGET) should have a 32-bit parameter for
passing/returning a PIN even though values no larger than 12000 will be
returned.
The comment in the documentation might be trying to point out that these GETPROCINFO and PROCINFO refer to different PIN's when you use the value of 0 (zero). In GETPROCINFO you pass a PIN value of 0 (zero) to request information about your parent (father) and in PROCINFO you pass a value of 0 (zero) to request information about yourself (caller).
The item with the
seventh most votes on the 2003 SIB was “Verify FTP/iX for > 8GB files both
ways, fixing any problems discovered. Known problems include slowness when
FTPing bytestream files. Make sure FTP is industrial strength.” In a series of
postings, summarized here, James Hofmeister, of HP’s Global Solutions Engineering
(WTEC), reported:
“FTP Patches are now available to support >4Gb file transfer from MPE to non-MPE systems. These site-specific patches also include other previously customer tested FTP fixes. Primary SR's fixed: 8606-293906 ‘FTP NT&UNIX - 501 Client is not Compatible to Create Large File.’ and 8606-294908 ‘FTP PUT fails to MPE with BUILDPARMS; REC=#; DISC=# >4Gb’
·
FTPHD42 for
C.65.00
·
FTPHD43 for
C.70.00
·
FTPHD44 for
C.75.00
“Site Specific FTP Patches are also now available to support >4Gb file transfer from MPE to non-MPE systems with performance improvements & fixes to support >=40Gb file transfers. Primary SR's fixed: 8606299250 ‘FTP Performance improvements for >4Gb file transfers’
·
FTPHD46 for
C.65.00
·
FTPHD47 for
C.70.00
·
FTPHD48 for
C.75.00
“These patches are site-specific and are not available for download from the HP-ITRC. If you have a HP S/W support contract you can call the Response Center at 1-800-633-3600 and request the appropriate FTP patch for SR 8606299250 for MPE release 6.5, 7.0 or 7.5.
“This series of
patches includes several changes in support of greater performance of files
> 4Gb size. Multiple solutions have been tested and the current
implementation has been found successful in our test suites. We currently are
only sending this series of patches out to customers who transfer files of a
size > 4Gb and who are willing to test this functionality and give
performance feed back to the HP Response Center on their success or problems
seen.
“The current test
suite results for these patches are:
·
MPE to HP-UX -
1Gb-60Gb passed
·
MPE to NT - In
progress 9Gb passed
·
MPE to MPE -
In progress 1Gb-9Gb passed
“Currently the FTPHD48 patch for C.75.00 is receiving the most customer site testing and will be the earliest candidate to be rolled into a GR patch. Note: We are continuing the investigation of FTP Performance above 4Gb and further improvements may come in the near future.”
Thanks James. For those who doubted HP’s claim it would continue to enhance and fix MPE to solve the problems its customer are seeing, this is a good example showing that the lights are still on.