net.digest – April 2002

Again this month talk about the merger moved to the forefront as both sides got in their final licks prior to the vote. Last month in the March issue I said, "Of course, by the time you read this, the outcome will probably be known." It appears I was a bit premature since, even as I write this in late March, we have only HP Management’s claim of a narrow victory but few facts to go on. It is entirely possible that even by the time you read this, a decision will not be final. However, I do stand by my prediction: "the only sure thing is that regardless of the outcome, everyone involved will come out of this diminished."

On the general topic of the future of the HP 3000, I’m going to self-indulgently quote something I posted to HP3000-L: "I seem to be getting more snail mail promotional pieces about the HP e3000 in the last 2 months than in the previous several years combined. Too bad the same marketing zeal was not applied while the HP e3000 was still breathing on its own and had a chance to survive. While I'm at it, it would be nice if CSY would stop rationalizing about the decaying ecosystem and own up to this fact (which many of us have been saying for years). HP signed the death warrant for MPE 10-12 years ago when it marginalized the HP 3000 as a niche platform and started promoting HP-UX as its only general-purpose operating system offering." I particularly remember fighting this battle with Rich Sevik during his unlamented reign as GM of CSY.

As long as I’m taking shots, I might as well point out that through this column and others, including its editorial content, The 3000 NewsWire takes the word "Independent" in its masthead seriously. This contrasts with our toady user group, Interex, which seems incapable of standing up to HP management by giving voice to the desires of its membership. [OK, it is later than I would have preferred, but Interex appears to be finally coming around to supporting its members. The day before this copy was due, I was allowed to preview an excellent article by Board member Denys Beauchemin. The article was scheduled to be available at the Interex web site and through other means on or about 3/28. It expresses what many of us have been asking Interex to say and is officially now Interex policy. If you have not already read it, do so. It’s forcing me to rethink my plans to drop my 20+ year association with Interex.]

Even though the merger and the future of MPE continued to dominate HP3000-L, there were still hundreds of postings where people graciously shared technical information. We report on some of them here.

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.

Advanced Telnet Returns

It seems like it has been gone forever, though of course, it was barely even here. Advanced Telnet, which is really analogous to the old half-duplex mode we graybeards remember, can be utilized by QCTerm to mask the delay when traveling long distances over the Internet. Wirt Atmar, whose AICS Research developed QCTerm loves to use Advanced Telnet with QCTerm to demonstrate interactive usage between a PC in the US and an HP 3000 in South Africa that "looks" as if the two machines are in the same building. James Hofmeister of HP announced the return of Advanced Telnet:

Re: Advanced Telnet Returns - SR 4701-422436

TELNET SUPPRESS LOCAL ECHO OPTION & XON/XOFF FLOW CONTROL

This functionality is primarily used in the QCTERM product from AICS Research, Inc.

For further details see:

http://raven.utc.edu/cgi-bin/WA.EXE?A2=ind9806D&L=hp3000-l&P=R54119

The patch that returns this functionality to Telnet is now available for 6.0 (and is expected to be available for 6.5 and 7.0 in the next few weeks):

PTDGDC7 for C.60.00 is Beta Test

If you require this functionality, please contact the HP-Response Center and request the Telnet enhancement SR 4701-422436.

As long as we are announcing good news,

in mid-March, Jeff Vance of CSY posted the following:

"Just a quick note to say that CSY R&D has completed the SIB request to allow customers access to their disk space on LDEV 1 beyond the first 4 GB. This enhancement will first appear in mainline release 7.5. As of now a patch to earlier releases is not planned due to the nature of the fix. A Communicator article should appear on Jazz shortly. "

Jeff went on to give the details from memory, but I'm not going to repeat them here - just keep watching for the article on Jazz. Denys Beauchemin spoke for many of us when he said: "I just wanted to say I am very pleased this important enhancement has been done. In my mind, this enhancement was critical to the viability of homesteading and the success of OpenMPE. A few years from now, when your ldev 1 disk drive breaks, you will no longer be faced with the problem of buying a 160GB disk drive (the smallest available) and only being able to use 4GB. This also means that A-Class systems become more desirable since you will now be able to have access to all 72GB of the 2 internal 36GB disk drives."

This passed on HP3000-L with virtually no comment, perhaps because of the general malaise and sense of hopelessness that seems to have plagued the user community of late. But take note, this is a BIG deal.

Wonder when that CI function or variable was added?

With many sites on MPE/iX 6.0, 6.5, 7.0 and even 5.5, the question is frequently raised whether some particular CI functionality is available. Jeff Vance provided the following list beginning with MPE/iX 6.0:

MPE/iX 6.0

POSIX filename were extended to support these special characters: ~\$%^*+|{}: and all CI commands that accept POSIX names support these chars.

the COPY command accepts a space separator between the to= and from= names, and the to= name can be a directory name.

the SHOWVAR command allows an SM user to see user defined vars for another job/session via the JOB= parameter.

the anyparm(), basename(), decimal(), dirname(), fqualify(), fsyntax(), and xword() CI functions were introduced.

MPE/iX 6.0 Exp 1

the jobcnt(), jinfo(), and wordcnt() CI functions were added.

the HPDATETIME, HPDOY, HPHHMMSSMMM, HPLEAPYEAR, HPYYYYMMDD CI variables appeared.

the JOB= argument of the PAUSE command allows job vs. session to be distinguished, as one can do with jinfo().

user defined, multiple job queues were introduced.

MPE/iX 6.5

the NEWCI command was added.

some CI support for Large Files (;ksam64 keyword, etc.)

MPE/iX 6.5 Exp 3

ABORTPROC command, requires OP or SM capability.

INPUT command can write the prompt to and accept input from the system console.

FOS STORE can write to disk (store-to-disk feature).

MPE/iX 7.0

HPMAXPIN read-only CI variable.

MPE/iX 7.0 Exp 1

pinfo() CI function was introduced.

4 new items added to jinfo(): waiting, suspended, scheduled, executing.

MPE/iX 7.5

new CI level command SHUTDOWN with a RESTART option.

Boy, this list is great and never ceases to amaze

A couple of months ago, I noticed that the Apache/iX job that powers www.burke-consulting.com was experiencing strange behavior when viewed in Glance: "Below is a cut and paste from Glance on my test and development machine [Editor’s note: omitted here]. Anyone care to speculate what Apache/iX is doing? Note Glance says JSMAIN under the APACHE logon is using 75% of the CPU every other Glance time cycle. I've checked the Apache logs and do not see anything unusual. I've bounced the Apache/iX job, but the behavior resumes immediately. I have another 3000 running Apache and it does not exhibit this behavior (the machine with the problem is running Apache/iX 1.3.9 on MPE/iX 6.5 PP2 - the other machine is Apache/iX 1.3.4, I think, on MPE/ix 6.0 PP2). The only significant difference in the machines is the one with the odd behavior is exposed to the Internet (for HTTP only). But, again, the logs do not show anything unusual."

Well, of course, I went off in pursuit of some strange Apache/iX bug. Then I considered the possibility an attempt was being made to hack into my computer. Within an hour of my original post, Guy Paul responded, later confirmed by Lars Appel, that this was a known Glance bug fixable by a stageable patch not requiring a reboot.

Gotta love HP3000-L. There is nothing else like it.

SCSI – the most confusing four letter acronym?

Hardly a month goes by when someone does not ask a question about SCSI connectivity. Here is a quick primer from Steve Dirickson:

SE (single-ended): TTL-level signals referenced to ground; speeds from 5Mhz to 20MHz

Differential (HVD): something around +/-12V signals on paired wires (old-timers think "EIA 20mA current loop"); same speeds as SE

LVD (Ultra2): TTL-level differential; 40MHz clock

Ultra160: same as LVD, but data signals double-clocked, i.e. transfers on both clock transitions like DDR DRAM

LVD and Ultra160 can co-exist on the same bus with SE devices, but will operate in SE mode. HVD doesn't co-exist with anything else.

When heartbeat loss means heartache

SQE heartbeat loss can lead to all sorts of network and system performance problems. Usually either a defective transceiver or a transceiver that has not been configured correctly causes this. So how do you diagnose if you have a heartbeat loss problem and where it might be? Doug Werth and Gilles Schipper combined to provide a good troubleshooting guide to determine if you have a heartbeat loss problem:

The first thing to do is check for heartbeat losses on the LAN card. Heartbeat losses on the system card cause slow network throughput most notable in large file transfers. The LINKCONTROL command can show you if the transceiver on the HP3000 system itself is not providing SQE heartbeat. For example,

:linkcontrol @;status=all
Linkname: DTSLINK Linktype: IEEE8023 Linkstate: CONNECTED
Physical Path: 56/56
Current Station Address: 08-00-09-98-18-D3

...

Trans late collision 0 Size range errors 0
802 chip restarts 0 Receives dropped 0
Heartbeat losses 0 Receives broadcast 6605
Receives multicast 0

You should see heartbeat losses of 0 or very close to 0.

Lack of SQE Heartbeat on DTCs can cause system performance problems and is not reported by the LINKCONTROL command. A DTC 'complains' to the host system that it is missing SQE. The host system, your HP3000, will log the heartbeat loss events to special log files stored on LDEV 1. These log events occur continuously resulting in an I/O bottleneck on the system disk. On some systems you can actually hear the system disk getting constant usage.

How do you diagnose if you are subject to this problem? Frequently the process that is logging the errors appears as the top DISC consumer in SOS or Glance/iX. Or a system process will continually appear in a list of active processes as seen in the :SHOWQ command.

:showq;active

DORMANT RUNNING

Q PIN JOBNUM Q PIN JOBNUM

A 39

C M163 #S9136

C M183 #S9140

D U189 #J6036

A stack trace of PIN 39 would point to a performance problem. Not only is this process logging the heartbeat loss events, it is forcing a post of the records to disk immediately via FCONTROL. This is where the performance problem lies.

Another method to investigate if you have this problem is to check for the log files themselves. The system will write one set of log files for each DTC configured on the system. The names of the log files are HxxxxxxA.PUB.SYS and HxxxxxxB.PUB.SYS where 'xxxxxx' represents the last 6 characters of the

12-digit Ethernet/MAC address of the DTC. For instance, if the MAC address is 08-00-09-00-75-BD then the file name will be H0075BDA.PUB.SYS.

:listf h@a.pub.sys,2

ACCOUNT= SYS GROUP= PUB

FILENAME CODE ------------LOGICAL RECORD----------- ----SPACE----

SIZE TYP EOF LIMIT R/B SECTORS #X MX

H0075BDA* 1W FB 5 66010 1 256 1 *

If the EOF of this file is very large then you should verify the SQE settings on the transceiver connected to that DTC.