ROC Software Sponsor Message

Net.digest summarizes helpful technical discussions on the comp.sys.hp.mpe Internet newsgroup and 3000-L 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

“Do we have a president-elect yet?” That’s how I started out last month’s column. As I write this, in mid-December, we now finally have a winner — or at least a designate. Of course someone could challenge a slate of electors in Congress. As we all prepared for the true beginning of the new millennium, discussion of the election mercifully tapered off. But it was replaced by plenty of other good off-topic threads.

There was, of course, a healthy dose of seasonal, off-topic humor. Add to that the discussions about where the original Thanksgiving celebration occurred, about PCs that “call home” without you knowing anything about it, about the sale of Open Skies, about the meaning of “kemosabe” and about life on Mars. Pretty diverse, huh? Amazingly, there was still enough energy around to generate a lot of good technical tips and tricks, some of which are contained here and in Hidden Value.

As always, I would 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 3000-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@paccoast.com.

Where oh where has my Store-to-Disk gone?

A user writes on 3000-L: “Since the ITRC has been down all day [Ed. note: the ITRC is probably worth a whole month’s net.digest sometime], I thought I would check with you folks. Earlier this year HP issued a patch for 6.0 that would allow regular FOS STORE to create store-to-disk (STD) files. Does anyone know if there is a corresponding 6.5 patch yet, and if so, what the patch ID is?”

Jeff Vance, of CSY, responded with a mixture of good news and bad news: “The 6.0 version of the patch is MPEKXR8 (which has probably been superceded). There is not yet a 6.5 version. It is in FOS in the 7.0 mainline release.”

There followed a lot of concern that customers moving to MPE/iX 6.5 from MPE/iX 6.0 would risk losing functionality they had been accustomed to. Furthermore, it was wondered whether this could turn into a deciding factor for customers evaluating which OS version to move to in upgrading from MPE/iX 5.5. One user pointedly asked if there was any other functionality present in 6.0 but not present in 6.5?

Jeff responded in late November thus: “To my knowledge, the patch MPEKXR8, which contains: store-to-disk, ABORTPROC and INPUT to console, is the only 6.0-based patch without equivalent functionality in the latest 6.5 PowerPatch. This is mostly my fault, as I did not have time to move this patch to 6.5 and do the high-priority release 7.0 work. I have forwarded your concerns to my manager and to HP Support.”

A little history: MPEKXR8, which was released as a site specific patch in February 2000, is wholly the work of Jeff Vance and would not exist at all if he had not championed it. The patch contains three or four (depending upon how you count) pieces of functionality that had been publicly requested by SIGMPE and SIGSYSMAN for several years:

• Store-to-Disk as part of FOS (previously this was only available if you purchased the high-end TurboSTORE/iX 7x24 True Online product).

• The :ABORTPROC command to kill one or more individual processes.

• An enhanced :INPUT command which can do I/O to the system console and includes provision for a default value if no user input.

• An enhanced input() function that mimics the INPUT command.

As one of my graduate school mathematics professors used to say in describing certain concepts, “It is intuitively obvious to the casual observer” that this functionality is extremely useful in day-to-day operations.

As Jeff correctly surmises, MPEKXR8 has been superceded by the MPE/iX 6.0 General Released patch, MPELX57A, which is available online at the ITRC (Note this is not in MPE/iX 6.0 PowerPatch 2, the latest PowerPatch for MPE/iX 6.0). Of course, you would not know any of this by looking at the $%%@#%$ ITRC (there I go again). Searching for MPEKXR8, ABORTPROC, “store to disk”, etc. comes up empty. I had to place a call to the RC where it look all of about 30 seconds to come up with MPELX57A. So why can’t we look up the same information? But wait, it gets worse. Look up MPELX57A and you will still find no reference to store-to-disk, ABORTPROC or INPUT. The only thing connecting MPELX57A to MPEKXR8 is the patch supercedes list.

MPEKXR8 was stageable — I was a Beta tester. Whether MPELX57A is stageable or not is undeterminable from the ITRC listing. I hope so, but I guess I will not know until I unpack it and start Phase 1 of Patch/iX. <shameless_personal_plug> I will be doing a session on Managing Patches at the 2001 Solutions Symposium on February 8. </shameless_personal_plug>

In mid-December, I contacted Jeff Vance for an update on MPE/iX 6.5 availability. He reported “There is a new patch ID for 6.5 (MPELXG2) that was just produced. I will be getting this patch on to a 6.5 release sometime in December, I hope.”

The HFS filespace can be your friend

If forced to admit it, I suspect many people continue to heavily use UDCs because:

* they do not have the time to convert a multi-thousand line UDC file into several hundred command files; or,

* they think the UDC is the only way to create “long name” commands.

In the first case, well what can I say? Since a big UDC file, or worse, a bunch of interdependent UDCs files, are more difficult to maintain in general, can you afford not to convert?

In the second case, you most certainly do not need to use UDCs to create “long name” commands. You may need to be a little creative in how you organize things, but otherwise, you have been able to execute MPE command files that lie in the HFS filespace since MPE/iX 5.0 Express-3. I have seen sites where the conversion has been done, but the UDC files remain simply to retain the “long names”: Each command in the UDC file is now only one line long, the call to the corresponding command file. Clearly, the logon UDC can not be duplicated with a command file; however, even in this case, if you make the only executable line of the UDC a call to a command file, you improve maintainability.

Donna Garverick and Jeff Vance provided the following information.

Starting with MPE/iX 5.0 Express 3 (see the documentation at jazz.external.hp.com/papers/Communicator/5.0/exp3/ci_enhancements.html), command files can live in and be executed from the HFS. You need to add an HFS directory name (/ACCT/GROUP/ or /ACCT/GROUP/directory/ for example) to your HPPATH variable if you want the script name to be qualified via the HPPATH mechanism. However, if you want to execute a qualified HFS named script, such as “/bin/foo.cf” or “./mybin/foo”, HPPATH is ignored and thus does not need an HFS element added.

There are some ambiguous cases, involving HPPATH qualification, where a script name can be considered both an MPE name and a HFS name. In all cases the MPE interpretation has precedence over the HFS interpretation. For example, a script named “a/b” can be considered an MPE name with an inline lockword, or a HFS named file “b” in the subdirectory “a”. Also, the script named “file.grp” can be an MPE file (“file”) in the group “grp” in the logon account, or it can be an HFS named file “CWD/file.grp”.

Now here is where the creativity comes in. Because these “long name” command files live in the HFS filespace, the names are case sensitive whereas the UDC command names are not. In the not so distant past, this would not matter much because PC terminal emulators, and especially terminals, were set up with “caps lock” on. In this case, you could certainly create your “long name” command files as all upper case. However, it is much more common now to not set “caps lock” on, so you have to be able to accommodate both uppercase and lowercase forms of the command (we’ll assume that only tortured souls mix case when executing commands). Obviously, having two copies of each file, one lowercase and one uppercase would work, but it would increase, not decrease maintenance costs. The solution: symbolic links. Create your command file in either uppercase or lowercase (enforce consistency for your own sanity) and then create a symbolic link in the same location (MPE group or HFS directory) using the NEWLINK command, but with the opposite case.

Dang (I figure I need to start talking Texan), that Posix is cool stuff

Someone asked how he could copy multiple files from one group to another. Without using that well-known third-party tool. A number of people responded with the usual suspects:

• If you have NS3000, then DSCOPY allows wildcards in the source.

• Use STORE/RESTORE to disk/tape.

• LISTF to a file, then edit it to create a command file of individual copy commands.

• Create (or download from various sources) a command file that applies any command to a fileset.

• Call FTP and loop back on yourself using the MGET command.

A few people threw in, along with their proposed solution, something like “I suspect you can do this using the Posix shell, but I’ll leave the explanation to others as I never use this myself”.

To which I increasingly say, why not? I have to admit I’ve been in the “never use this myself” camp, with the usual excuse of “I don’t have the time to learn it”. This is often accompanied by a slight sneer of disdain as if the Posix shell has a disagreeable odor to it. Well, we’ve all got to get over it and make the time. The shell (and I’d add Mark Bixby’s Perl port) represent a tremendous, mostly untapped, resource for system administrators and programmers. Want a quick example? Tom Brandt’s solution to the proposed problem: use the shell’s cp command.

cp * /ACCT/GRP/

will copy all the files in the current working directory (which can be an MPE group) into the MPE group GRP.ACCT. Obviously, you can be more selective then just all files. Furthermore since cp is implemented using the MPE copy command (see man cp), all the MPE attributes are preserved in the copies.

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