The juices were flowing in August. In case you’ve been marooned on a deserted 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, this did not sit too well with the denizens of HP3000-L. In less than a month, this thread, and those spawned from it, generated over 600 postings. 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 News/Wire. Amazingly, these postings were in addition to and not instead of, the normal flow of technical and not-so-technical postings to HP3000-L in any given month. For the period 7/21 through 8/20 there were over 2300 postings to HP3000-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 HP3000-L that addresses what I feel are needed changes at CSY.

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, 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:

On 7/14, OnOn Hong, CSY R&D, noted on HP3000-L in reply to a question about the availability of e-speak 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.

- OnOn Hong. HP CSY R&D."

The previous day, in a chat on 3KWorld, 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 (I&I team, R&D lab. 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

-----------

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 can not 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 homerun every time. And may even strike out a few times. But 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 the game completely.

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 at first thought because in general this configuration value only applies to 3000-to-3000 communications. According to James Hofmeister of HP’s WW 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 James Hofmeister noted in a later posting to HP3000-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.

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:

Bummer. As the original poster says, "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 WW 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 over come between the 3k and non-3k systems. These problems were specific (again from my best recollection) to the lack of a read trigger arriving from remote non-3k systems. The problem this difference in I/O design methodology presented was the non-3k system could not predict when the 3k 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 PP3 and above. The remsh client allows an HP3000 "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 results of their 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. Then Lars Appel, not to be outdone, presented a Java program that could be used to create a "session" on a remote computer. These thoroughly modern techniques are available now. On the HP e3000. [Both can be found in the HP3000-L archives. Look for the subject "Batch HP3K Telnet Access?"]