net.digest September 2003

September 2003

Net.digest summarizes helpful technical discussions on the HP 3000 Internet newsgroup and mailing list. Advice here is offered on a best-effort, Good Samaritan basis. Test these concepts for yourself before applying them to your HP 3000s.

Edited by John Burke

August saw HP World 2003 pass by much of the 3000 community, even though it offered the last gathering of MPE-IMAGE aficionados before HP ends HP 3000 sales this October 31. By most other measures, HP World 2003 was a huge success.

The consensus among the people I have talked with is that the majority of HP 3000 users are sitting on their hands for the time being and are not actively involved in any transition. Fewer than 600 MPE customers were at HP World, according to the Interex user group. Interex’s attendance information came out in a 3000-L thread about the Interex post-conference survey. The thread questioned the relevance of HP World — and by extension Interex — to HP 3000 users. Some people proposed models for a conference separate from Interex, from something dubbed “HP 3000 World 2004” to a meeting like the old IPROF, held at HP’s California facilities. 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. You can reach me at john@burke-consulting.com.

Even more on SCSI is SCSI

A key talk at HP World came from HP’s Jim Hawkins (the MPE/iX IO Team Lead) titled “Future Proofing Your HP e3000 Mass Storage.” Hawkins indicated his slides would be posted on HP’s Jazz Web server at some point. As of this writing they have not, nor have they been posted along with many other slide sets at the HP World Web site.

One rumor Hawkins confirmed involved Ultrium (LTO) tape drives. Hawkins’ team tested them with Turbostore and third-party backup products. Turbostore performance was disappointing; however, the performance of third-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 third-party backup utility, I suggest you contact your backup vendor for further information.

Hawkins reported that HP is working on disk support beyond 146GB, 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, DDS-5, Ultrium 460, future SCSI JBOD and future FC JBOD. HP has no plans to investigate Ultra 320 SCSI (which would require a new driver) or future FC Host Bus Adapters.

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 okay.

Someone suggested that perhaps at some point, certainly by end of support for the HP 3000, 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 3000s running. The response from vCSY, both at Hawkins’ session and in later conversations, was mostly positive. As Co-Chair of SIGMPE, I promise to keep this issue out in front.

Is MPE forward or backward compatible, or both?

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 on the mailing list:

“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 third-party tools. Most third-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 3000s. Certainly a testament to HP and their efforts at providing a stable business computing environment.”

What’s a PIN?

The following question was posted on 3000-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 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 12,000 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 32,767 processes. (During the original design of HPE, which became MPE XL and then 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 PINs 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).

Item # 7 on the SIB

The item with the seventh highest number of votes on the 2003 SIB was “Verify FTP/iX for greater than 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 recent postings summarized here, James Hofmeister of HP’s Global Solutions Engineering (WTEC), reported on HP’s work.

“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.’ Patch numbers are FTPHD42 for C.65.00, FTPHD43 for C.70.00 and 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.’ Patch numbers are FTPHD46 for C.65.00, FTPHD47 for C.70.00 and 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 software support contract you can call the Response Center at (800.633.3600 in the US) 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 feedback 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 to James. For those who doubted HP’s claim it would continue to enhance and fix MPE to solve the problems its customer are seeing, these patches are a good example showing that the lights are still on at HP.

John Burke is the editor of the NewsWire’s HiddenValue and net.digest columns and has more than 20 years’ experience managing HP 3000s.