- Integrated Systems
- About Us
- Integrated Systems
- About Us
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
02-12-2010 04:38 AM
$ 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??
Solved! Go to Solution.
02-12-2010 05:11 AM
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.
02-12-2010 05:22 AMSolution
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.
02-12-2010 05:31 AM
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.
02-12-2010 05:38 AM
%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...
02-12-2010 05:47 AM
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.
02-12-2010 05:54 AM
you can do the first analysis steps yourself:
SDA> SET PROC "PMDF counters"
SDA> SHOW PROC
... look for Event Flag Wait mask
SDA> READ SYSDEF
SDA> FORMAT JIB
This information should get you started diagnosing the MUTEX wait state.