%SHOW-W-NODE_ERROR

[The Brit]

Can anyone shed any light on this error message??

$ Show User/Full
%SHOW-W-NODE_ERROR, unable to display information from node BUD
-SYSTEM-F-BADPARAM, bad parameter value

OpenVMS User Processes at 12-FEB-2010 02:02:59.31
Total number of users = 5, number of processes = 13

Username Node Process Name PID Terminal
END_NIGHT BUD EON_CLOSEDAY 203AE57B (Batch)
END_NIGHT CITIUS (DET) INVRETR 204085D9 (Batch)
END_NIGHT CITIUS EON_AUTOLET 20421126 (Batch)
END_NIGHT CITIUS EON_CLEANUP 2041C969 (Batch)
END_NIGHT CITIUS EON_DIARY 2041F525 (Batch)
END_NIGHT CITIUS EON_OESBACKUP 2041F242 (Batch)
END_NIGHT CITIUS EON_SHIPWORK 20422128 (Batch)
END_NIGHT ECOM (DET) QUOMOVR 20600466 (Batch)
END_NIGHT ECOM (DET) VENDEDI 20600467 (Batch)
END_NIGHTINQ BUD BATCH_2303 2020D873 (Batch)
KUFF SPEEDY BATCH_2231 20E0849D (Batch)
REFRESHER CITIUS BATCH_2306 20419D6A (Batch)
SYSTEM BUD PMDFF8 tcp_loca 203E7096 (Batch)
$!

The command is being run, in batch and on Node BUD, in a nightly script which has not been modified in almost a year. This error has not been seen before.

$ help /message SHOW-W-NODE_ERROR
%MSGHLP-F-NOTFOUND, message not found in Help Message database

Has anyone seen this before??

Dave

[Thomas Ritter]

Are we dealing with a cluster and trying to show nodes from node to another ?
SMISERVER running ?

[The Brit]

We are running in a cluster (3 Nodes, BUD, CITIUS & SPEEDY), however the command is being executed on Node BUD, and the error is "... unable to display information from node BUD".

Interestingly, it immediately follows up by displaying the information it claims to be unable to display.

I suspect that the command (unluckily) collided with some other process trying to access the Process Table.

Dave.

[Volker Halle · Accepted solution]

Dave,

I've found a mention of a %SHOW-W-NODE_ERROR in c.o.v. from 11-JAN-1991 ;-) But I don't remember ever seeing this myself.

[CLIUTL]SHOWUSER reports this error in routine jpidone_ast, if the IOSB contains an unexpected status.

$GETJPI works with the CLUSTER_SERVER process on the remote nodes, not with SMISERVER. So check that process on node BUD. Or maybe there are some processes on node BUD in a questionable state ?

And maybe try some F$GETJPI calls yourself to node BUD to determine, what the problem may be.

Volker.

[Volker Halle]

Dave,

SHOW USER/FULL did display some users from node BUD and just reported ONE error.

It's calling $GETJPI with a completion AST and continues with the next $GETJPI call (from the AST) until receiving ss$_nomoreproc. It would signal a SHOW-W-NODE_ERROR for any unexpected error in this loop.

So there seems to be exaclty ONE process on BUD, which causes $GETJPI to fail with SYSTEM-F-BADPARAM, you just need to find that process ;-)

I don't expect there to be any issues walking the process list.

Volker.

[Volker Halle]

Dave,

%SYSTEM-F-BADPARAMS could be returned by $GETJPI, if the item list contains a bad identifier. The item list for each call is built in P0 memory of SHOW.EXE - it might be hard to further diagnose this...

Volker.

[The Brit]

Thanks for the very useful information Volker, you sent me in the right direction I think.

Looking at the system process list I found;

OpenVMS V8.3-1H1 on node BUD 12-FEB-2010 08:39:42.28 Uptime 61 06:36:38
Pid Process Name State Pri I/O CPU Page flts Pages
2020042D PMDF counters MUTEX 6 1259748 0 00:02:07.23 6122 5655 M

I notice that this process is in Mutex state on all of my cluster nodes and standalone nodes (that are running PMDF).

I will be forwarding this issue to Process Software.

thanks for your help.

Dave.

[The Brit]

I think the above is the source of the problem so I will forward it to Process Software for investigation.

Dave.

[Volker Halle]

Dave,

you can do the first analysis steps yourself:

See
http://h71000.www7.hp.com/wizard/wiz_2347.html

$ ANAL/SYS
SDA> SET PROC "PMDF counters"
SDA> SHOW PROC
... look for Event Flag Wait mask
SDA> READ SYSDEF
SDA> FORMAT JIB
SDA> EXIT

This information should get you started diagnosing the MUTEX wait state.

Volker.