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

Apparently, no one took a vacation in July, as the torrent of postings to 3000-L continued. As usual, mixed in with the not-to-be-found-anywhere else technical information, were off-topic, very off-topic and totally, completely, wildly off-topic threads. We were treated to discussions on everything from the Second Amendment to the Constitution to a list of fantasy books suitable for children of all ages (a spin-off from a thread about the amazing sales of the latest Harry Potter book). The gun control thread was distinguished by the usual passion coupled with an uncommon civility that speaks to the general quality of even off-topic postings to 3000-L.

In addition to these threads, readers could try to follow an informative discussion on the mapping of the human genome. Or read the hand wringing speculation on why, if HP’s lawyers refer to the HP e3000 as the “crown jewel” in the court room, HP can not treat the HP e3000 as something other than an embarrassing relative in the marketplace. Or, how about the fifth face on Mount Rushmore? I am constantly amazed at the depth and breadth of knowledge displayed for all to read on 3000-L.

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.

Network printing: the Good, the Bad, and the Ugly, Part 2

Last month, I spelled out what you can and cannot do with the MPE/iX network print spooler. I also determined that under all documented printing configurations, the network print spooler (OUTSPTJ) spits out the following PCL, at a minimum, at various times:

• <esc>Z turn off display functions

• <esc>E printer reset

• <esc>%-12345X the Universal Exit Language (UEL) command

• <esc>&l0V conditional top of form

My goal in this investigation was to see if there was any way to use a non-HP (and therefore most likely non-PCL) impact printer as a network printer. Please note, I am not trying to save the money a third-party solution would cost (as I said last month, we already own one), nor am I trying to sabotage the existing third-party suppliers. Rather, I would just like the sheer convenience of a completely integrated printing solution.

CSY steadfastly refuses in public to even consider enhancing network printing, the argument being “there are third-party solutions that do the job.”

My first thought was that, since HP has never really acknowledged the “snmp_enabled=false” directive, maybe there is a similar undocumented directive that would disable the PCL requirement for the printer. I used a combination of fcopy (with the hex and char options) and quad (with display functions turned on) against a copy of the network spooler program OUTSPTJ to convince myself that there is no secret directive.

So, when all else fails, what do real nerds do? Read the manual!

In looking over the documentation for network printing for something, anything, I spied the npconfig.pub.sys directive “program_file,” with the definition:

“Name of the output spooler program file invoked for the network printer. Default is OUTSPTJ.PUB.SYS.”

Hmmm, I said to myself. Apparently CSY created a hook for possible future, different spoolers. Writing a spooler from scratch, especially since there are no published APIs I’m aware of, seemed rather daunting. But, I thought, what if I were to create my own spooler by taking a copy of OUTSPTJ and replacing the PCL directives above with either nulls or the corresponding reset code for a particular personality-class of printer? In this case, since I was working with a printer that used the Epson personality, I could replace <esc>E with <esc>@ and everything else with nulls. I called the result OUTSPEPS.PUB.SYS and put the “program_file=OUTSPEPS.PUB.SYS” directive in my npconfig file for the test printer.

I used Quad to do this, and feeling pretty good about myself, tried to fire up the test printer with a startspool. Bzzzt! On the console I get the message:

:7:56/88/Output spooler, LDEV #2098: The program_file item of NPCONFIG.PUB.SYS must be either OUTSPTJ.PUB.SYS or /SYS/PUB/OUTSPTJ (case sensitive).

Native Mode Spooler message 9670

7:56/88/Output spooler, LDEV #2098: Stopped.

Aaargh! #$@^%$%# HP! The only thing worse than an undocumented feature (see “snmp_enabled=”, “nscontrol killsess=”, etc) is a documented feature THAT DOES NOT WORK!

How was I going to test my brilliant hypothesis? Fortunately, I have the luxury of having a crash and burn machine – at least until a part I can not easily replace breaks down. I renamed OUTSPEPS to OUTSPTJ.PUB.SYS, defined my printer (make sure to turn headers off if you decide to try this at home, since otherwise the spooler fails in a rather ugly manner), and fired up the spooler. I took a deep breath and peeked at the console: No errors. So far, so good.

I sent a couple of test spool files to the printer and, wonder of wonders, they printed just fine!

So much for proof of concept. But, unfortunately, that is all it is, proof of concept. That is, at least until CSY implements the “program_file=” directive for NPCONFIG first described in the MPE/iX 5.5 Communicator four years ago. And, while it is at it, how about CSY releasing the source to OUTSPTJ? If it is not going to be enhanced, then why not?

Anyone at CSY listening?

SYSSTART and STARTSESS

In Hidden Value this month, there is a question about how to create a SYSSTART file and what it can do for you. There was a comment at the end about some people using STARTSESS in the SYSSTART file to automatically logon OPERATOR.SYS at the console during a system startup. This particular idea, and how to make it work, was the subject of another thread on 3000-L.

Of course, as we all know, the default behavior on a startup is to attempt to logon OPERATOR.SYS at the console. But someone has to respond to a password request (You do require passwords on OPERATOR SYS, don’t you?) when you rely on this default. On a large system, this can be difficult as messages fly across the screen, so it would be nice to just log onto the console without requiring a response. Also, depending upon the situation, a boot from tape for example, you might want to default the logon to, say, MANAGER.SYS and not have to go through the extra effort of a second logon.

In the example case that started this thread, the user site enforced session name logons through a system-wide logon UDC and therefore wanted the console logon to have a session name. In particular, their SYSSTART file contained the line:

STARTSESS 20;CONSOLE,OPERATOR.SYS;NOWAIT;HIPRI

But it did not seem to work. The reason became obvious when the documentation for the STARTSESS command was consulted:

“All required passwords must be specified in the command invocation; STARTSESS will not prompt the caller or the ldev for passwords. Omitting a missing password where one is required will cause the command to fail.”

So, it appears that to use STARTSESS in a SYSSTART file, you must embed the passwords in the command line. But, by default, everyone has read access to PUB.SYS; so what is one to do? Expose your SYS account passwords to prying eyes? Not necessary. Several people pointed out that you could issue the command:

ALTSEC SYSSTART;(R,L,X,W,A:CR)

to secure the file from prying eyes, but that you needed to take care when editing the file that the security is not altered. For example, EDITOR will generally alter security back to the default, which would be read by everyone. You need to check how your favorite editor handles the security matrix for files you are modifying. Lars Appel noted that the undocumented SET SECURE directive within EDITOR would preserve the security matrix for the file you are editing. By the way, whether you use STARTSESS in your SYSSTART file or not, I think it is a good idea to secure this file on general principles.

Several people suggested an enhancement request that would override password checking for SYSSTART processing or, perhaps, a JOBSECURITY equivalent for the STARTSESS command similar to what the PASSEXEMPT option provides for the STREAM command. I think this would be worth trying to get on the next System Improvement Ballot; however, as we read on 3000-L this month, adequate workarounds do exist. You just have to be careful.

Thanks go to Tracy Johnson for pointing out something that I think many of us forgot about, if in fact we were ever consciously aware of it. The ISL START command supports a “LOGON=” option. Thus you can start your system with something like

START NORECOVERY LOGON=CONSOLE,MANAGER.SYS

This form also supports the “/PASSWORD” construct so that your system can come right up from scratch ready to go with a colon prompt displayed. Tracy also suggested including this in your AUTOBOOT file, should you use that feature.