Hidden Value February 2005

Hidden Value details commands and procedures in MPE that can improve your productivity with HP 3000 systems. Send your tips to john@burke-consulting.com

Edited by John Burke

I wanted to load the latest FTP patch for MPE/iX and went through the needed steps to get the files onto my system. However when I ran PATCHIX, it said the patch did not qualify. I know I could ‘force’ the patch, but I’m puzzled why the patch does not qualify in the first place.

Guy Paul replies:

Make sure you are on the latest Patch/iX version first. If it still won’t qualify there is a f-key you can press that should give you more details on why it won’t qualify. Most likely it is a checksum problem. If you made any changes to the catalog or help file this would change the checksum. Forcing it should be okay in this case and you can always back it out with STAGEMAN.
[Editor’s note: Another common cause for checksum failure, is applying a lockword to the file or renaming something. I often did both these with QUERY. The lockword was to prevent normal users from accessing it and the rename was used before NM QUERY became QUERY. Both caused checksum failures when patching. Forcing the patch worked just fine.]

Is there a way to successfully process an MPE file with a lockword using its HFS (Posix) name?

Tom Emerson and Gavin Scott reply:

I think the short answer is you can’t. The longer answer is that, in Posix terms, there is simply no concept of a “lockword,” hence no ability to specify such. MPE does not consider a file an HFS file when you’re in an MPE GROUP at the time you try this. Files with lockwords that exist outside of MPE GROUPs have their lockwords deactivated until such time as the file is moved back into an MPE group. If the file is in a GROUP and it has a lockword, then you must specify the lockword in order to open the file, and there’s no way to embed a lockword into HFS syntax and there’s no way to pass the lockword independent of the filename (that we know of). Also the open won’t prompt for a lockword if you use HFS syntax to name it.

The port for telnet on our 3000 is set to a different value then 23, but it is set to 23 on our 9000. When I try to telnet from the 3000 to the 9000 I get the following message: Trying... telnet: Unable to connect to remote host. If I switch the port for telnet to 23 on the 3000, it works great.
My question is: Can I run telnet on two different ports on either box so that I can maintain my non-standard port on the 3000, but still allow telnet to run between the two boxes? If not, is there another way to make this work?

Jeff Kell replies:

Just ‘telnet your.3000.name nnn’ where ‘nnn’ is your ‘nonstandard’ port.