By Gilles Schipper
A recent query on the 3000-L newsgroup about converting DTC configuration from OpenView-based to host-based brought up some memories — as well as lessons learned about significant CPU-intensive excesses as the result of improper DTC setup and configuration. In the early 1990s, with the advent of HP 3000 host-based telnet, one of our customers no longer needed their DTC Telnet access card (TAC) to enable network online access to their HP 3000.
And since the TAC was the primary reason they utilized Openview DTC Manager, they asked if it was possible to eliminate the additional hardware, software, and management overhead associated with Openview DTC Manager.
The answer, of course, was yes, definitely and absolutely — or so we thought.
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.