net.digest December 1997

Click here for TSG sponsor message

Hidden Value details commands and procedures in MPE that can improve your productivity with HP 3000 systems. Get a free NewsWire HP 3000 Always Online cap – submit your MPE tip directly to us here at the NewsWire. Send your tips to rseybold@zilker.net, or fax them to 512-657-3264.

Compiled by John Burke

In trying to support our ever-changing network, I’m increasingly concerned that the nsconf/nsdir entries I’m making via online NMMGR are correct. It’s entirely too easy to make a typo or get distracted. Is there any way to do this through a batch process?

Lars Appel replies:

Anything you can do in NMMGR Maintenance Mode (the command line interface) can be done in batch by simply redirecting the formal file designator NMMGRCMD.

[Editor’s note] The following comes from the Using The Node Management Services (NMS) Utilities manual:

“Maintenance mode commands are read from the formal file designator NMMGRCMD, which defaults to $STDINX. You can redirect the input to come from a standard ASCII file by using a file equation for NMMGRCMD.

“You can also access maintenance mode directly from a batch job by running NMMGR from a stream job or by running NMMGR with a file equation for the formal designator NMMGRCMD set to a command file. An example of such an equation is:

:FILE NMMGRCMD=CMDFILE

“Command input is echoed to $STDLIST if you are running NMMGR from within a stream job or when the input is read from a command file.

“You can create a command file using any editor that is capable of generating straight ASCII output. Blank command lines may be entered freely.”

Chris Bartram adds:

If you’re doing that much network address manipulation, you’d likely be much better off to set up a DNS server somewhere and just point your 3000 to it (using RESLVCNF.NET.SYS and /etc/resolv.conf). [Note: the system running your DNS server can also be your 3000, thanks to Mark Bixby’s port of the BIND nameserver.] Once you point to DNS, you needn’t ever bother with going into NMMGR’s directory again. And one central system (though preferably with a secondary server to back it up) can answer name-to-IP-address resolution questions for your entire network.

My DTC temporarily lost communication with my HP 3000. Communication has been restored but a printer attached to the DTC that was active when communications went down is no longer working. I’ve power-cycled the printer and tried all the options for the SPOOLER and SPOOLF commands I know to no avail. The spoolfile printing when communications went down still shows active and will not clear, delete, defer, etc. What can I do? I do not want to have to reboot the HP 3000.

Art Bahrs, Gilles Schipper and Klaus Franke reply:

If you’re using host-based DTC management , try:

:SYSDIAG SYSDIAG> TERMDSM TERMDSM> RESET LDEV nnn

If you’re using OpenView DTC Manager, you can reset the LDEV from the DTC Manager console. In either case, you will likely need to again :STARTSPOOL nnn to get the printer going.

Does the following message point to a bad DAT tape?

STORE ENCOUNTERED MEDIA WRITE ERROR ON LDEV 8 (S/R 1454) SPECIFICALLY, STORE RECEIVED ERROR -44 FROM THE IO SYSTEM (S/R 1557)

Jeff Woods replies:

According to the text of a copy of the LLIO (Low Level I/O, aka Subsys 113) error numbers I inherited somewhere along the way, a -44 error is called llio_hw_problem and means “This mgr’s device had a hardware error for which no other statistics are available.” As is the case with most unanticipated LLIO errors, the problem could be with the media, the drive mechanism, the drive firmware, the SCSI (or analogous) bus, the device adapter, or even the driver software on MPE. In my experience, it’s usually the media or the mechanism. If other tapes seem to be having problems, even intermittently, then I would expect the drive to be the problem. If not, then pitch the tape. With the cost of DDS media so low, if there’s any doubt as to the integrity of a scratch tape, I think it should simply be disposed of.

How long can a CI command line be?

HP’s Jeff Vance replies:

In release 5.0 Express 3 (and maybe earlier) the CI’s command line buffer was increased from 279 to 511 bytes. The RUN command is parsed by the MYCOMMAND intrinsic and has a 255 byte token limit, so the info= string on the run command is limited to 255 bytes. However, “implied run” (like, XEQ progname “info”) supports an info value up to as much as remains in the 511 byte CI buffer.

I’ve developed a mental block on the command to reset job and spool numbers. What’s the command?

Per Ostberg, Mike Dobies, Dave Carroll and Jerry Fochtman all replied before the cyber ink was dry:

Check out HELP SETCOUNTER.

[Editor’s note: This question, and the answer, serve as an example of why we need something better and more widely available than LaserROM for MPE. SETCOUNTER is one of those commands that is either really, really useful and you’d never forget it – how many remember trying to accomplish a simple reset of spoolfile numbers using privilege mode DEBUG or, worse, a reboot? Or, you could care less – I’ve been there too. By the way – Pssst, pass it on: There may be relief in 1998 for all us long-suffering users of LaserROM.]

After taking a power hit last night, our 947 came back fine but now the console message line keeps flashing EA40 then EF40. I have no idea what those flashing indicators are telling me. I don’t even know which manual I would have to look in.

Pete Crosby, Fred Metcalf, Art Bahrs and Chris Hill reply:

The indicators will stop as soon as the memory backup battery has recharged. HP’s Pete Crosby provided an extended explanation:

The e#40 status is normal in your circumstance. It is an indication that the battery is recharging after a PFAIL. The second character will vary from 0-f and is the same as normal, giving a rough estimate of CPU utilization (0=idle, f=pedaling as fast as it can). The message will go away once the battery is fully charged. The annoying thing about it is that it beeps at you and makes using the console a pain. You can request and install MPEHXF1 to turn the ‘functionality’ off.

I am trying to configure a DTC as “switchable” using MPE/iX 5.5’s new functionality but can’t get the “second” system to be recognized by the DTC. I have configured the DTC in NMMGR on both systems. I gave the DTC the same “DTC NODE NAME” on both systems. I used the same profiles on both systems and I have double checked the MAC address on the unit with what is listed in NMMGR on both systems. I did a reset on the DTC from sysB and it “timed out,” which indicates the system can’t “see” it. This DTC has been working fine on sysA for months. It still seems to be working fine on sysA, I just can’t get to sysB. What do I need to do?

Jeff Bandle, Alan Ambers and Jim Wallace reply:

There are actually two ways to solve this problem. The first is to use host-based management and configure the MAC address as all 0’s. The second way is to specify on the system that isn’t managing the DTC to use OVDTCMGR as the management platform. This will accomplish the same thing and will also give you the use of the non-nailed pools for accessibility from the DTC.

With the introduction of switching for host-based managed DTCs, the NMMGR question about using OVDTCMGR as the management platform has become somewhat fuzzy. What the question is really trying to address is whether the MPE system is managing DTCs directly or not. If not, then some other machine is managing them, whether it’s an OVDTCMGR PC or another HP 3000.

Twice today my NS/VT session has been aborted. The second time it happened I ran right quick to the console and found this error message:

NS/3000 NetIPC Error in VT: Job: #S3379; PIN: 61; Info: 1 - Error: 42Whatever can this mean?

Ken Vickers and HP’s Jim Hofmeister reply:

The Error Messages book says “REMOTE NOT RESPONDING, CONNECTION CLOSED.” The remote (remote from 3000) VT closed the connection. The session has been terminated.

The two most common causes of this message are:

1. The user powered down the PC (terminated Client VT Service and TCP Transport) without first logging off the 3000 (:bye).

2. Another user on the network has the same (duplicate) IP address as your system. When this PC powers up its TCP transport, we have a new mapping of IP to MAC address of the new PC’s LAN card – and now when data is sent to this new client transport, it is not in the state to expect this data and does not respond with ack, etc, so the connection is closed and session on the 3000 dropped.

If you receive the 42 after an extended period of inactivity – in particular the client TCP stops responding – then KEEP-ALIVE comes into play. This timer can be found in NMMGR at: “Path: NETXPORT.GPROT.TCP”.

[600] Connection Assurance Interval (Secs)

[4] Maximum Connection Assurance Retransmissions

The default timeout is 10 minutes for four retransmissions (total 40 minutes) of client TCP not responding and NO data transfer on the TCP connection. When a connection is dropped on a CA timeout, you should see a message from TCP warning of a “CONNECTION ASSURANCE TIMEOUT” as well as the VT ERROR 42.

Original material copyright 1997, The 3000 NewsWire. All rights reserved.




		Click here for TSG sponsor message

		Hidden Value details commands and procedures in MPE that can improve your productivity with HP 3000 systems. Get a free NewsWire HP 3000 Always Online cap – submit your MPE tip directly to us here at the NewsWire. Send your tips to rseybold@zilker.net, or fax them to 512-657-3264. Compiled by John Burke In trying to support our ever-changing network, I’m increasingly concerned that the nsconf/nsdir entries I’m making via online NMMGR are correct. It’s entirely too easy to make a typo or get distracted. Is there any way to do this through a batch process? Lars Appel replies: Anything you can do in NMMGR Maintenance Mode (the command line interface) can be done in batch by simply redirecting the formal file designator NMMGRCMD. [Editor’s note] The following comes from the Using The Node Management Services (NMS) Utilities manual: “Maintenance mode commands are read from the formal file designator NMMGRCMD, which defaults to $STDINX. You can redirect the input to come from a standard ASCII file by using a file equation for NMMGRCMD. “You can also access maintenance mode directly from a batch job by running NMMGR from a stream job or by running NMMGR with a file equation for the formal designator NMMGRCMD set to a command file. An example of such an equation is: `:FILE NMMGRCMD=CMDFILE` “Command input is echoed to $STDLIST if you are running NMMGR from within a stream job or when the input is read from a command file. “You can create a command file using any editor that is capable of generating straight ASCII output. Blank command lines may be entered freely.” Chris Bartram adds: If you’re doing that much network address manipulation, you’d likely be much better off to set up a DNS server somewhere and just point your 3000 to it (using RESLVCNF.NET.SYS and /etc/resolv.conf). [Note: the system running your DNS server can also be your 3000, thanks to Mark Bixby’s port of the BIND nameserver.] Once you point to DNS, you needn’t ever bother with going into NMMGR’s directory again. And one central system (though preferably with a secondary server to back it up) can answer name-to-IP-address resolution questions for your entire network. My DTC temporarily lost communication with my HP 3000. Communication has been restored but a printer attached to the DTC that was active when communications went down is no longer working. I’ve power-cycled the printer and tried all the options for the SPOOLER and SPOOLF commands I know to no avail. The spoolfile printing when communications went down still shows active and will not clear, delete, defer, etc. What can I do? I do not want to have to reboot the HP 3000. Art Bahrs, Gilles Schipper and Klaus Franke reply: If you’re using host-based DTC management , try: `:SYSDIAG SYSDIAG> TERMDSM TERMDSM> RESET LDEV nnn` If you’re using OpenView DTC Manager, you can reset the LDEV from the DTC Manager console. In either case, you will likely need to again :STARTSPOOL nnn to get the printer going. Does the following message point to a bad DAT tape? `STORE ENCOUNTERED MEDIA WRITE ERROR ON LDEV 8 (S/R 1454) SPECIFICALLY, STORE RECEIVED ERROR -44 FROM THE IO SYSTEM (S/R 1557)` Jeff Woods replies: According to the text of a copy of the LLIO (Low Level I/O, aka Subsys 113) error numbers I inherited somewhere along the way, a -44 error is called llio_hw_problem and means “This mgr’s device had a hardware error for which no other statistics are available.” As is the case with most unanticipated LLIO errors, the problem could be with the media, the drive mechanism, the drive firmware, the SCSI (or analogous) bus, the device adapter, or even the driver software on MPE. In my experience, it’s usually the media or the mechanism. If other tapes seem to be having problems, even intermittently, then I would expect the drive to be the problem. If not, then pitch the tape. With the cost of DDS media so low, if there’s any doubt as to the integrity of a scratch tape, I think it should simply be disposed of. How long can a CI command line be? HP’s Jeff Vance replies: In release 5.0 Express 3 (and maybe earlier) the CI’s command line buffer was increased from 279 to 511 bytes. The RUN command is parsed by the MYCOMMAND intrinsic and has a 255 byte token limit, so the info= string on the run command is limited to 255 bytes. However, “implied run” (like, XEQ progname “info”) supports an info value up to as much as remains in the 511 byte CI buffer. I’ve developed a mental block on the command to reset job and spool numbers. What’s the command? Per Ostberg, Mike Dobies, Dave Carroll and Jerry Fochtman all replied before the cyber ink was dry: Check out `HELP SETCOUNTER`. [Editor’s note: This question, and the answer, serve as an example of why we need something better and more widely available than LaserROM for MPE. SETCOUNTER is one of those commands that is either really, really useful and you’d never forget it – how many remember trying to accomplish a simple reset of spoolfile numbers using privilege mode DEBUG or, worse, a reboot? Or, you could care less – I’ve been there too. By the way – Pssst, pass it on: There may be relief in 1998 for all us long-suffering users of LaserROM.] After taking a power hit last night, our 947 came back fine but now the console message line keeps flashing EA40 then EF40. I have no idea what those flashing indicators are telling me. I don’t even know which manual I would have to look in. Pete Crosby, Fred Metcalf, Art Bahrs and Chris Hill reply: The indicators will stop as soon as the memory backup battery has recharged. HP’s Pete Crosby provided an extended explanation: The e#40 status is normal in your circumstance. It is an indication that the battery is recharging after a PFAIL. The second character will vary from 0-f and is the same as normal, giving a rough estimate of CPU utilization (0=idle, f=pedaling as fast as it can). The message will go away once the battery is fully charged. The annoying thing about it is that it beeps at you and makes using the console a pain. You can request and install MPEHXF1 to turn the ‘functionality’ off. I am trying to configure a DTC as “switchable” using MPE/iX 5.5’s new functionality but can’t get the “second” system to be recognized by the DTC. I have configured the DTC in NMMGR on both systems. I gave the DTC the same “DTC NODE NAME” on both systems. I used the same profiles on both systems and I have double checked the MAC address on the unit with what is listed in NMMGR on both systems. I did a reset on the DTC from sysB and it “timed out,” which indicates the system can’t “see” it. This DTC has been working fine on sysA for months. It still seems to be working fine on sysA, I just can’t get to sysB. What do I need to do? Jeff Bandle, Alan Ambers and Jim Wallace reply: There are actually two ways to solve this problem. The first is to use host-based management and configure the MAC address as all 0’s. The second way is to specify on the system that isn’t managing the DTC to use OVDTCMGR as the management platform. This will accomplish the same thing and will also give you the use of the non-nailed pools for accessibility from the DTC. With the introduction of switching for host-based managed DTCs, the NMMGR question about using OVDTCMGR as the management platform has become somewhat fuzzy. What the question is really trying to address is whether the MPE system is managing DTCs directly or not. If not, then some other machine is managing them, whether it’s an OVDTCMGR PC or another HP 3000. Twice today my NS/VT session has been aborted. The second time it happened I ran right quick to the console and found this error message: `NS/3000 NetIPC Error in VT: Job: #S3379; PIN: 61; Info: 1 - Error: 42`Whatever can this mean? Ken Vickers and HP’s Jim Hofmeister reply: The Error Messages book says “REMOTE NOT RESPONDING, CONNECTION CLOSED.” The remote (remote from 3000) VT closed the connection. The session has been terminated. The two most common causes of this message are: 1. The user powered down the PC (terminated Client VT Service and TCP Transport) without first logging off the 3000 (:bye). 2. Another user on the network has the same (duplicate) IP address as your system. When this PC powers up its TCP transport, we have a new mapping of IP to MAC address of the new PC’s LAN card – and now when data is sent to this new client transport, it is not in the state to expect this data and does not respond with ack, etc, so the connection is closed and session on the 3000 dropped. If you receive the 42 after an extended period of inactivity – in particular the client TCP stops responding – then KEEP-ALIVE comes into play. This timer can be found in NMMGR at: “Path: NETXPORT.GPROT.TCP”. [600] Connection Assurance Interval (Secs) [4] Maximum Connection Assurance Retransmissions The default timeout is 10 minutes for four retransmissions (total 40 minutes) of client TCP not responding and NO data transfer on the TCP connection. When a connection is dropped on a CA timeout, you should see a message from TCP warning of a “CONNECTION ASSURANCE TIMEOUT” as well as the VT ERROR 42. Original material copyright 1997, The 3000 NewsWire. All rights reserved.