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

The juices were flowing in August. In case you’ve been marooned on a desert island for the last month with no communication to the outside world, it all started when HP’s Ann Livermore was quoted as saying “We have a multiple-operating system strategy: HP-UX, Linux and NT.” Naturally, the omission of MPE did not sit too well with the denizens of 3000-L. In less than a month, this thread, and those spawned from it, generated over 600 messages. The postings were still going strong when I had to break off to do Hidden Value and net.digest. As I write this, I have no idea how it will all turn out, but you can be sure it will be covered by the 3000 NewsWire. (See our FlashPaper for the latest on the campaign to get corporate HP to recognize the strategic value of the e3000.)

Amazingly, these postings were in addition to, and not instead of, the normal flow of technical and not-so-technical postings to 3000-L in any given month. For the period 7/21 through 8/20 there were over 2,300 postings to 3000-L! Boy, did I have my work cut out for me. So perhaps you will indulge me a little. The first item this month is a reworking of a posting I made to 3000-L that addresses what I feel are needed changes at the e3000 division (CSY).

As always, I would like to hear from readers. 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.

HP management needs an attitude change, but CSY must also change its developing attitude

CSY is rightly proud of its “Customer Focused Engineering.” However, like most good things, when carried to an extreme it becomes a liability. In particular, if you consistently wait until a critical mass of customers request certain functionality before acting, I believe you will consistently be late in providing that functionality — and will therefore drive some percentage of customers (those who refuse or cannot wait) to another platform. Consider the following thread:

OnOn Hong, a CAY R&D engineer on the Internet and Interoperability solutions team, noted on in reply to a question about the availability of HP’s e-speak language on the HP e3000:

“An early version of the e-speak prototype has been running on MPE/iX 6.0 since last year. However, we have not pursued the e-speak technology any further due to the lack of demands from our customers. Please let us know if you are interested in integrating your MPE applications and providing e-services using e-speak.”

The previous day, in a chat on 3kworld.com, there was the following dialogue (edited to identify participants and for continuity):

Peggy Ruse (Marketing Initiatives Manager in the Internet and Interoperability Area): By the way, HP WebWise does not equal the MPE/iX secure Web server... HP WebWise will eventually be populated with other offerings.

Chris Bartram (3K Associates): Peggy, if you’re accepting wish list items; ODBC (client) for e3000 (so Web servers can pull data from local OR remote servers), and MS FrontPage extension support on the HP e3000.

OnOn Hong (Working with Peggy, I am responsible for the HP e3000 Internet strategy and roadmap.): Sounds good.

Peggy: I always want wish lists and hope to turn them into real life offerings.

Barbara Dubbert (CSY engineer supporting Apache Web server): Chris, can you give us an idea of your priority for MS FrontPage Extensions?

Chris: Peggy, right now it’s only a “nice to have”. For us it’s too late (already have multiple Linux boxes running Web servers because they did support FrontPage). Still, so many folks are using it and it really makes managing a complex Web site a snap — even for beginners.”

Readers, note what Chris said: “For us it’s too late...”

In the case of FrontPage Extensions, I’ve had similar conversations with CSY for the past two years. For many people, a window of opportunity has been missed. They were forced to use another platform because functionality they needed was not available on the HP e3000. Are we going to be saying the same thing about e-speak in a year or two: another missed opportunity for CSY and the HP e3000?

In this era of IT moving at “Internet speed,” there is no time for CSY’s old development model. If CSY continues to wait until the customer demand reaches some critical mass before embarking on new technologies, it will continue to be too late to the party.

I know CSY cannot do everything, but a little proactive leadership is needed here. Identify a handful of technologies that might take off and make sure the HP e3000 is ready when they do. Clearly, there is risk in leading. CSY will not hit a home run every time — and may even strike out a few times. But I believe the penalty for not taking a proactive leadership role in determining the direction of the HP e3000 is far worse than striking out a few times. It is losing this game completely.

To enable TCP checksum, or not, that is the question

And the answer is, yes. You should configure “TCP checksum enabled” to “Y”, regardless of what you may have read anywhere else.

However, suppose you are setting up a new system. You are plowing through NMMGR screens and you get to the “Checksum Enabled” configuration parameter found in NMMGR at Path: NETXPORT.GPROT.TCP.

If you press [F7] Help you get the following information on this parameter:

Checksum enabled (Y/N)

Specifies whether or not checksumming will be enabled in the local configuration. Checksumming causes significant overhead and is not normally needed for this protocol; therefore, HP recommends the default value (N) for this field unless communication to a non-HP machine is desired…

Default Value: N

Range: Y or N

Chances are, absent any other information, you’d leave it at the default: No.

Which would be wrong, wrong, wrong. Though it would not be as wrong as many on the newsgroup first thought, because in general this configuration value only applies to 3000-to-3000 communications. According to James Hofmeister of HP’s WorldWide Technology Network Expert Center:

“One point to keep in mind — this discussion is only appropriate for 3000-to-3000 connections. If a non-3000 system is connecting to your system and performing communications via sockets or a FTP file transfer or a Telnet session you are already using TCP Checksum and there is no way to turn it off since TCP Checksum is the ‘industry’ RFC standard.”

It turns out that this help screen is left over from MPE VE days. As Hofmeister noted in a later posting to 3000-L, in tests run on several current systems, the overhead from TCP Checksum processing was negligible. Measure that against the possibility of data corruption and you can see why HP now strongly officially recommends setting “Checksum enabled” to “Y.”

In fact, Jim has submitted his test results in the form of a SR (8606155933) that requests the default of “Checksum enabled (Y/N)” be changed to “Y” and the help documentation updated.

Batch telnet? Don’t hold your breath — But there’s more than one way to skin this cat

You may or may not be aware that MPE/iX contains a telnet client (telnet.arpa.sys) and has for some time. Try it out. It seems to work in the simple cases I’ve tried.

So, it is natural that someone would want to use this telnet client in a batch job. However, when they tried, they got:

Sorry, this program cannot be run from a job.

Bummer. As the original poster said, “All I want to do is basic ‘Joe Telnet’ stuff, connect to another system, dialogue a bit, and gracefully quit. I need to do it in batch because:

• It needs to be done at certain human-unhealthy hours.

• The dialogue needs to be recorded ($stdlist), saved, then hopefully e-mailed to someone.

• It’s the same commands each time, so it begs to be batched anyway.

• It’s pretty important, and so it needs to be done on the platform with the best up-time <grin>.”

It turns out there are a number of alternatives, one old, two fairly recent, and two very new that might do the trick.

But, first, will we ever be able to run the telnet client from batch? Not likely. From James Hofmeister of HP’s WorldWide Technology Network Expert Center:

“Significant investigation went into Batch Telnet Access by CSY labs and from my best recollection it was determined that timing issues could not be overcome between the 3000 and non-3000 systems. These problems were specific (again from my best recollection) to the lack of a read trigger arriving from remote non-3000 systems. The problem this difference in I/O design methodology presented was the non-3000 system could not predict when the 3000 system would send data. I know of no current or future plans to implement batch Telnet access.”

OK, so what can you do if you face the same situation?

If both systems are HP e3000s and both have NS3000, then you can do DSLINE/REMOTE HELLO from batch. I’ve used this functionality for many years. In fact, I remember doing just this in the early 1980s.

So, what if the systems are not both HP e3000s, or you do not have NS3000?

It is possible that FTP’s “site” command will work, depending upon your requirements. Or, if the target machine supports the remshd daemon, MPE/iX now supports the remsh client. This was first introduced in the MPE/iX 6.0 Communicator; however, the client software actually works on MPE/iX 5.5 PowerPatch 3 and above.

The remsh client allows an HP 3000 “client” system to connect to a remote “server” system and execute a single command on that system. Output from the remote command is sent to remsh’s standard output so the user can see the result of the command. The server can be any system connected to the network that has implemented the remshd daemon using TCP/IP. [Note: remshd has not been implemented for MPE/iX.] The user may run the remsh client from either the Posix shell or from the MPE/iX prompt. Documentation for the remsh client can be found in “Configuring and Managing MPE/iX Internet Services.”

I promised you two new alternatives. First, Mark Bixby presented a Perl script that used “Net::Telnet” to communicate with a remote system:

#!/PERL/PUB/perl
$username = ‘youruser’;
$passwd = ‘yourpass’;
use Net::Telnet ();
$t = new Net::Telnet (Timeout => 10,
Prompt => ‘/\]\$ $/’);
$t->open(“yourhost”);
$t->login($username, $passwd);
@lines = $t->cmd(“/usr/bin/who”);
print @lines;