We made meticulous plans to reconfigure the DTC-associated devices to use host-based DTC configuration, instead of the current OpenView-based configuration.

Coincident with the enabling of that new configuration, we could discard all the OpenView-required extraneous hardware — such as the Openview Windows for Workgroups 3.11 workstation, as well the required Windows, OpenView and associated DTC software. The telnet card in the DTC could also be decommissioned.

At the same time, we decided to convert the DTCs from thinlan BNC connections to 10base-T RJ-45 connections. The project was to be implemented one weekend after all users had been notified well in advance.

Cutover time came and we proceeded to make the planned changes. We copied our newly modified nmcfgnew file onto NMCONFIG.PUB.SYS and subsequently performed a graceful shutdown of the HP 3000.

Then, we needed to partially disassemble each DTC48 in order to change the large jumper switch therein to enable the MAU port instead of the BNC port.

After re-assembling each of the four DTCs, we attached a transceiver to each of them and attached to the LAN via Cat-5 cables to a hub.

After rebooting the HP 3000, we immediately noticed a problem.

The activity light on LDEV 1 was abnormally high and we noticed very sluggish response time, even though only the console was signed on and no batch jobs were executing.

Having no idea what the problem was — and also absent any tools such as Glance to shine a light on the situation — we began to revert to the pre-conversion configuration, software and hardware.

This meant reverting back to OpenView-based configuration, as well as BNC DTC connections.

Only a week later, with some analysis of the NM log files, were we able to establish what was going on. Long story short, the problem was related to the transceivers and the fact that SQL heartbeat was disabled for all of them. The result was that the CPU was being inundated with an overwhelming amount of IO requests in order to log the missing heartbeat event in the NM log file.

This unnecessary and voluminous IO was enough to bring the system to its knees — even absent any other activity.

In today's HP 3000 environment, this serious CPU wastage problem can be overlooked, because faster CPUs could render the problem relatively less noticeable.

But I would venture to guess that there is a lot of the "wasted IO" that is affecting a large number of HP 3000s out there.

Fortunately, there is a very simple way to recognize whether the problem exists, and also a simple cure.

If your DTCs are connected without transceivers, you will not be subject to this problem.

Otherwise, to determine if you have the problem, simply type the following command and look at the reply that follows:

:listf [email protected],2

ACCOUNT=  SYS         GROUP=  PUB

FILENAME  CODE  ------------LOGICAL RECORD-----------  ----SPACE----
                  SIZE  TYP        EOF      LIMIT R/B  SECTORS #X MX

H000000A*           1W  FB           5      66010   1      256  1  *
H000000B*           1W  FB           0      66010   1        0  0  *
H0909A5A*           1W  FB           5      66010   1      256  1  *

H0909A5B*           1W  FB           0      66010   1        0  0  *
H13ECEEA*           1W  FB           5      66010   1      256  1  *
H13ECEEB*           1W  FB           0      66010   1        0  0  *
H15F669A            1W  FB           5      66010   1      256  1  *
H15F669B            1W  FB           0      66010   1        0  0  *
HASTAT    NMPRG   128W  FB         347        347   1      352  1  8
HAUTIL    NMPRG   128W  FB         424        424   1      432  1  8
HP32209B  PROG    128W  FB          15         15   1       16  1  1
....................................

Notice the OPEN files (the ones with the associated asterisk suffixing the file name) that are 1W in size.

There are two such files associated with each configured DTC, file name starting with the letter H, followed by six characters that represent the last six characters of the DTC MAC address, followed by the letter A or B. The EOF for these files should be 0 and 5 for the respective "A" and "B" files.

Otherwise your CPU is being subjected to high-volume unnecessary IO, requiring CPU attention. The solution is to simply enable SQL heartbeat for each transceiver attached to each DTC.

This is done via a small white jumper switch that you should see at the side of each transceiver.

Voila, you've just achieved a significant no-cost CPU upgrade.

There is also another method of eliminating this excessive CPU overhead that involves using NMMGR to uncheck as many logging events as you can for each DTC, revalidating and rebooting.

But the SQL-heartbeat enable method is a surer bet.

For those HP 3000 users concerned about the impending HP support termination – or those looking for a more personalized support offering — please consider GSA Inc.

We have been offering HP3000 System Administration Support Services throughout North America since 1983 – longer than any other third-party HP support provider.

You can visit us at www.gsainc.com for more information.