net.digest August 2001

August 2001

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

I was thinking it was going to be a slow month for Off Topic threads on 3000-L, but then we had a wild mouse ride of a thread that began with a fairly innocent David Greer sighting in France. About a week later, the “immediate tax relief” letters stated to arrive in the US. Wirt Atmar could not resist firing a shot across the bow and another long, wild thread was off and rolling.

The first lengthy thread started out with Birket Foster posting that he and family had run into former Robelle partner Greer and family in France (neither knew where the other would be, it was just total serendipity). This morphed into how to travel safely around the world (Birket had some cameras stolen), then morphed into how to translate certain Latin phrases and, finally, into whether Castro and Ho Chi Minh were Nationalists first and Communists second, or the other way around. You have to read it to believe it.

The second lengthy OT thread was started when Wirt opined: “Whether this ‘refund’ was merely very poorly explained or whether it is a purposefully deceptive sleight-of-hand on the part of the current administration, it is our understanding, as well as that of Ernst & Young’s, that almost everyone has come to misunderstand what this check really is.” After hundreds, if not thousands of words on the subject, some people still do not understand. Hint: “It is a purposefully deceptive sleight-of-hand” by the administration and its supporters in Congress. I guess you know where I stand.

But I digress to the extreme. As usual, there was a lot of very good technical advice delivered on 3000-L. Some that caught my eye follows.

I would like to hear from readers of this column 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 or john@burke-consulting.com.

You can’t quite get there from here, and a possible enhancement request

The question from the poster to 3000-L seemed simple enough: How could he display the results of an arbitrary command, command file or program run from a session or job on the system console? It turns out this is not as simple as it seems it should be.

If you have a command file that uses ECHO to display information to $STDLIST, then, as several people pointed out, replacing all instances of ECHO with TELLOP will display, instead, to the logical console. Unfortunately, it also prepends the time of day and sending user on each line, which can get really ugly.

The enhanced INPUT command (available as a patch to 6.0/6.5 and part of base release 7.0) will allow you to “program” a dialogue with the physical console, LDEV 20. But, suppose you want to direct the entire, possibly multi-line, output of a command, command file or program to the console? What can you do? Command I/O redirection (CIOR) does not support something like $CONSOLE.

As Ron Horner pointed out, if you can ensure that the physical console (or any serial terminal device for that matter) does not have a session signed on to it, then the following works:

:file console;dev=ldev
:command or program >> *console

This might work for some sites, and does not prepend the output lines with anything, but certainly it’s not a general solution.

Ron Wuerth came up with an interesting Rube Goldberg-style approach that works if the command, program or command file generates only one line of output. Since it uses TELLOP, it works whether a session is signed on or not, but, of course, also prepends each line with time of day and sender. From the shell,

shell/iX> callci tellop `callci command or program`
[Note: the “back” quotes are necessary to make this work.]

A similar approach that works for multi-line results but stays within the CI is to first re-direct the output to a message file. Then, process the message file with a short CI script that reads each line and TELLOPs it to the console. Again, this has the downside of the prepended identifying text. If you are a little more ambitious, you could write a program that would read the re-directed output, then use the PRINTOP intrinsic to display each line to the console. The advantage is this does not prepend anything.

Donna Garverick was the first to suggest the $CONSOLE enhancement as the MPE/iX equivalent of the Unix /dev/console. Mark Bixby said, in essence, why an equivalent, why not the actual thing: “I think the better implementation would be /dev/console, because as a special file, it could be used from BOTH the MPE and the POSIX worlds, whereas $CONSOLE would only be usable from MPE.”

I think Mark has the esthetically right idea. But perhaps the practical approach, because it does not require precious CSY lab resources, is a little utility program using PRINTOP to display arbitrary information to the logical console.

From the “Why is it like that?” department

Or, MPE is the OS with tradition. A user asked, how does one determine block size in a BUILD command? HELP says that you can have a block size of up to 255, but what is that based upon?

The following command works

BUILD TEMPDF.PUB.ACCOUNT;REC=-
348,150,F,ASCII;DISC=10000,10,1

but this does not

BUILD TEMPDF.PUB.ACCOUNT;REC=-
348,255,F,ASCII;DISC=10000,10,1

Stan Sieler took a crack at the answer with the following posts:

“There are actually several questions here:

1. Why is 255 the maximum? 255 is the maximum because somewhere the Classic HP 3000 probably used an 8-bit field to remember the information. A cursory check fails to show where this might have been.”

Jerry Fochtman supplied the complete answer: “According to my MPE-V tables manual, blocking factor was contained in 1-byte located in the file’s File Control Block (FCB). The text further indicates that the only legal values were 1-255. If I recall, it was derived at open by dividing the block size by record length from the file label.” [Editor’s note: remember this was defined 30 years ago.]

Seiler added, “2. Why won’t 255 work with -348 record size? Many values larger than 150 work, like: 151 .. 188. 189 (and larger) won’t work:

:build foo;REC=-348,188,F,ASCII;DISC=10000,10,1
:purge foo

:build foo;REC=-348,189,F,ASCII;DISC=10000,10,1
INVALID RESULTANT BLOCK SIZE (FSERR 11)

Note that 348 * 188 is #65424, which is a bit less than 64 KB, and that 348 * 189 is #65772, which is a bit more than 64 KB. The maximum block is 65534 bytes, which allows:

:build foo; rec=-302, 217, f, ascii

You could try for 65535 bytes with:

:build foo; rec=-4369, 15, f, ascii

but it will fail.

“3. Should you even specify a block size? Why? Unlike Classic MPE, specifying a block size on MPE/iX systems matters little, except it may affect the performance of programs that open the file MR NOBUF.”

Keep it simple and avoid overkill

A user asked if there are any libraries available for the 3000 which will allow us to “encrypt/decrypt” a single field in an IMAGE database. He would soon have to store sensitive data on his production system and preferred not to have a particular character string understandable via third-party packages such as Quiz or Query.

At the same time, the data needs to be available programmatically via third-generation languages calling external routines in a protected library.

In this particular case, the person was not trying to protect against a sophisticated attack, but just prevent casual discovery. Two methods were proposed, both of which I have used successfully in the past.

Michael Berkowitz proposed a simple redefining of the field in the schema. For example, if the field was really a character string X32, redefine it as an array of 8I2. The advantage of this approach is its simplicity (a simple change to the database using something like Adager or DBGeneral) and it does not require any changes to 3GL programs. The one disadvantage (and you’ll have to determine how big a disadvantage it is for you) is that many Report Writers and query languages (but not Query) let you redefine fields, thus un-hiding data stored this way.

A second, almost as simple, way of encrypting the data was proposed by Gregory Stigers and elaborated on by Wirt Atmar. It involves flipping the bits. Thus ASCII A = 65(10) = 01000001(2) becomes 10111110(2) = 190(10). As Stigers says, “Simple to do, simple to undo, but not terribly obvious to the naked eye. Wirt noted that to mathematically create this simple form of bit complementation, you can use the subtract operator, subtracting from 2^n - 1, where n is the number of bits that your register of interest occupies.” In this case, for 8 bits: 255-65 = 190. A major advantage of this technique over the first is that it protects against the Report Writers and Query languages that allow you to redefine fields. However, you have to modify all the programs that access the fields that have been encrypted in this manner.

How about a return to yesteryear?

The preferred way to “abort” or “kill” the INETD job is inetd.net.sys -k

Simple enough. However, if you try it from a user without SM, say OPERATOR.SYS, you get the message:

inetd: This program requires SM capabilities

Okay, well that’s not terribly desirable. So, let’s try it from my SYSADMIN account where I have SM. No error messages, but the job continues merrily along.

As Doug Werth suggests, “With inetd, even a user with SM capability cannot kill it. It appears to be hardcoded for MANAGER.SYS. My guess would be that it started as source from UNIX that was programmed to look for root user (or UID 0) and chose to replace it with the closest MPE equivalent of MANAGER.SYS or UID 1.”

There followed several threads on this subject with the general consensus being that it would be desirable for operators (or at least those with OP capability) to be able to “kill” INETD properly. Several listers suggested this become an enhancement request.

Before we all got too carried away, Dennis Heidner presented an effective workaround: “Create a batch file that does the inetd.net -k. Set up the job to run as manager.sys. Change the file security to xeq only and put a lockword on it. The job can include the inetd.net -k, a pause, set a variable if JINETD is still running. If still running, then it can do an ABORTJOB. Anybody that has a need to shut down INETD can do so by streaming the job.”

Lars Appel suggested a variation: “Protect it with an ACD that grants X access to the desired users, and with the appropriate JOBSECURITY;PASSEXEMPT setting (XACCESS or MAX), they can then stream those jobs without having to supply MANAGER.SYS passwords.”

The point of all this? We seem to have gotten away from the spirit that existed in the past when the Interex Contributed Software Library was a BIG deal. There is a tendency now to want HP CSY to enhance something rather than look for acceptable workarounds. Another example? ping.net.sys does not support name resolution and, worse, requires NM and NA capabilities. Most agree ping should not require any special capabilities. Enhancing ping has ranked fairly high on past enhancement ballots. Yet there exists an excellent workaround. NSLOOKUP is part of the BIND package delivered with MPE/iX 6.0 and subsequent releases. NSLOOKUP provides name resolution. Lars Appel contributed a hacked version of ping.net.sys that removes the NM and NA requirements (he just no-op’d them out). This is an example of “hacking” the way it originally arose. Combine these two with a simple CI script wrapper and you have a very good ping usable by anyone.

My sense is that only a few people are taking advantage of this and other contributed software. And I don’t mean ported software, as good and as important as it is — I mean software written for the HP 3000 as the target platform. The original CSL has become unwieldy in this instant gratification age. Plus, it is the captive of Interex and access is controlled. Perhaps we need some Open Source projects, with the target system being MPE/iX.

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