net.digest October 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

The events of September 11 and their aftermath dominated the recent off-topic postings. As I prepare this column, not quite two weeks since my generation’s “Day of Infamy,” it does not feel right to summarize any of the silliness that took place on the list prior to September 11. For, just as I remember where I was and what I was doing when President Kennedy was shot, and when the first draft lottery was held, so will I remember where I was and what I was doing September 11, 2001.

Somewhat amazingly, there was still a lot of good technical advice delivered on 3000-L. For those of us who were fortunate not to be directly impacted by the tragedy, perhaps that’s all we can do, try to help someone.

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

Nifty Samba tricks

Samba/iX was the first Open Source utility ported to the HP e3000 — long before there was an “e” in HP e3000. It was ported by Lars Appel of the German Response Center, making use of Mark Klein’s port of the gnu c compiler. By now, most everyone knows that Samba/iX exists, that it allows you to define and access “shares” on your HP e3000 as if it were a Windows server, and that HP even supports it. I continue to be amazed though at how many sites still do not use Samba/iX. If you are one of those, perhaps you will see something here that piques your interest. Even though I’ve used Samba/iX since Lars’ original port, I learned a few things this month. Maybe you will too.

This month’s Hidden Value column contains an item showing how you can use the NET TIME command from your PC to time sync with an e3000 running Samba/iX. This posting prompted several people to contribute their favorite Samba tricks.

First, from Curtis Larsen:

“Although it is not especially cool, I’ve always thought the print server aspect was nifty. Using the ‘rawlp’ program, my HP e3000 makes for the most stable print server on the planet. It’s not a blazing fast print server mind you, but it’s still amazing.

“For ‘Downright Cool’ however, I would point out the ‘magic script’ entry for true geekishly good fun. It allows you to run any script mentioned based on the script being closed by the accessing client. In other words, if, while accessing an HP share with the (script) file ‘drink_me’ in it, I open and close that file, the system will execute it for me. This is a very handy way to run a script without logging on, and the possibilities are endless. You can even use the ‘magic output =’ entry to direct where the output of the script will be sent.

“A similar, but slightly trickier entry is ‘message command =’ which will run a specified command or script when the HP e3000 receives a ‘Windows pop-up message’ from someone. This little gem also allows for the inclusion and translation of many of the well-known Samba variables (like %w or %I) and offers a few new ones such as %s (the message filename), %t (destination machine), and %f (from). Again, the possibilities are wild. (NOTE: You need to end the message with an ‘&’ for it to return control immediately.)

“‘preexec’, ‘postexec’, ‘root preexec’, and ‘root postexec’ are all entries that allow scripts to be run at the respective times when a share is accessed. This is usually some sort of TELLOP-like thing (e.g. ‘TELLOP MA! He TOUCHED me! Did NOT!’), but can, again, be anything you want.

“A newer entry ‘preexec close =’ has some really interesting possibilities. It is a script that runs on access attempt that, based on its return value, either allows the access or not. (A nonzero return prevents access.)

“Okay, now the disclaimer: Beware. These configuration entries are dangerous. Every Samba book I’ve ever read says things like ‘strongly discouraged’ and ‘man, this could blow up in your face’. But yes, like anything of the sort, they can ALSO be very useful to you. Hide the shares you use this stuff with, lock them down so that only you can access them, and put them on a Development system. Then, play.”

While Lars Appel did not necessarily consider these “cool” or “nifty”, he added:

“With smbclient you can access shared directories and printers on client PCs, NT servers, and other Samba servers to get or put or print files (no MPE CCTL please). It can sometimes be kind of useful to pick up input data on a PC drive or deposit some batch results there (e.g. somefile.csv for spreadsheet import).

“The smbclient program even has a tar option that can pick up complete directory trees on the PC and archive them into a tar file on the 3000 side (or unpack a tar file to a PC directory tree). Assuming that the PC shared the respective drive area.

“Another exotic smbclient option is -M for Windows messaging, i.e. the 3000 side can send a Windows pop-up message to the PC user (who needs no MPE session logon). Can be nice for having a batch job report completion or fault conditions.

“Oh, and a twist to the print server functionality that Curtis already mentioned. Not every Samba printer needs to use rawlp to forward the printout into the MPE spooler. For example, we are using a ‘dummy’ Samba printer to ‘import’ customer address information from some NT-based workflow application into a patch tape-shipping tool (written in Java, using JDBC to access Image/SQL) without the NT application knowing about its ‘cooperation’. The user simply ‘prints’ to Samba and the custom ‘print command’ captures and parses the output to extract the information of interest and passes it to the MPE application (immediately, with no polling).”

Just when you thought you’d read the last piece about SYSSTART…

A new SYSSTART thread started with someone asking the question, does the SYSSTART file have to have certain characteristics to be recognized during the boot process? It seems his SYSSTART file was not being activated. Consensus was that the creator must be MANAGER.SYS and the file must have at least one correct keyword that matches the type of start. Many people also apparently believed the file needs to reside on LDEV 1. In fact, the documentation (it only took about a dozen posts before someone quoted the documentation) says the file must “reside on LDEV 1 to function properly.” However, experience from the field indicates this latter requirement is no longer necessary, if in fact it ever was.

SYSSTART is not forced onto an SLT and there was some talk about whether it should be, along with your favorite editor, for example. Note that you can specify anything be included as a system file, and thus be on an SLT, through SYSGEN. Several people pointed out that a better idea is to include a store as part of the SLT and on the same tape as the SLT (see documentation for SYSGEN’s TAPE command). A good STORE list, courtesy of Stan Sieler, is:

/SYS/ - /SYS/MPEXL/DUMPAREA - /SYS/PUB/NL - /SYS/PUB/SL,/TELESUP/;DIRECTORY

[Note: If you have user volume sets, you must explicitly mention them as part of the DIRECTORY parameter.]

INPUT, the CI command and function

This month’s “Hidden Value” contains an item about how to program “Hit any key to continue” in a CI script. The answer was to use a special form of the INPUT command. Jeff Vance, HP’s CI Architect, provided a few additional tidbits about INPUT: • The INPUT command also allows the read on $STDIN to be timed (wait= parm). Note that this is ignored in batch jobs unless “;CONSOLE” is specified.

• It also allows you to direct the prompt to the system console and capture the operator’s reply in the variable

• INPUT supports the specification of a default value for the variable.

• The variable is always a string variable, regardless of user input.

• There is a corresponding input() function.

The main differences between (a) :input foo,”prompt” vs. (b) :setvar foo input(“prompt”) are:

• In (a) the variable is not always set, e.g. user just hits return; in (b) foo will always be set.

• IO redirection is supported for (a) and not for (b).

See HELP INPUT and HELP INPUTFN for more details.

The console of the future?

Now that a few people are getting some real-world experience with the A- and N-class HP e3000s, some interesting questions are popping up on 3000-L. A thread about the system console was started when a user asked, “Has anyone figured out the keystrokes for the console of the new A- and N-boxes? It uses a PC keyboard. What keystrokes does one use to scroll-up/down?”

The answer, depending upon who you choose to believe, is either {shift}+{arrow key} or {ctrl}+{arrow key}. It seems HP has a new terminal that uses a PC keyboard. To put it mildly, those who have seen this new terminal are underwhelmed. As Stan Sieler offered, “find the nearest trash can and toss the terminal in it. I first saw one at HP World, and was amazed at how lousy it is. Not only is the keyboard missing important keys, but the performance is terrible.” Stan went on to suggest using a cheap PC with an emulator. Others noted that the older 700/9x terminals still work as A- and N-class consoles. Still others suggested the Secure Web Console.

But disparaging HP’s latest terminal offering is not why I’m writing about this thread. Rather, it is to take note of a posting from Doug Werth about the Guardian Service Processor on the A- and N-class systems. “Basically it’s an extra 10Base-T port on the back of the system that you connect to the network to provide telnet access to the console port. It is documented in the 7.0 Communicator in an article titled “MPE/iX A-Class and N-Class Console.” Here is an excerpt from that article:

“This port provides an independent LAN connection to the Core I/O card. This port has its own IP node and telnet server. This port is configured with an IP address, subnet mask and gateway address. When enabled, a connection is established to the port via telnet from any telnet client. The GSP provides the user and password protected logon. This is not a secure telnet connection.

“Once a user is logged onto the GSP, the user has the capability to perform almost all of the same console tasks that are available from the local console. This includes full startup and shutdown capabilities, remote power on/off control, and configure and control of most GSP operations. The system can be fully managed via a connection to this port. The physical LAN connection to this port is completely independent from the general system LAN and cannot be used to access other MPE functions. The GSP provides the functionality to locally and remotely manage the system console functions.”

Doug goes on to say, “The only advantage the Secure Web Console has over this is built-in encryption (giving you the ‘Secure’ part). But the advantage of using your own terminal emulator to connect to the telnet port far and away makes it better than the Secure Web Console terminal emulator applet.”

Pretty neat.