Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

TCPIP SHOW HOST Problem

 
Joseph Bianco
Occasional Advisor

TCPIP SHOW HOST Problem

When I use the TCPIP SHOW HOST command the following dump occurs.

TCPIP> show version

HP TCP/IP Services for OpenVMS Alpha Version V5.6 - ECO 2
on an AlphaServer ES40 running OpenVMS V8.3

TCPIP> show host

LOCAL database

Host address Host name

127.0.0.1 LOCALHOST, localhost
172.17.11.15 SAINTVIATOR.COM
172.17.11.5 SVHS
172.17.11.1 VIATOR1.SAINTVIATOR.COM, VIATOR1
172.17.11.2 VIATOR2.SAINTVIATOR.COM, VIATOR2
%LIB-E-KEYNOTFOU, key not found in tree
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=000000000000
005E, PC=FFFFFFFF80A98978, PS=0000001B

Improperly handled condition, image exit forced.

An nslookup for a host works without a problem
9 REPLIES 9
Steven Schweda
Honored Contributor

Re: TCPIP SHOW HOST Problem

I know nothing, but I'd guess that your
(local) hosts data base is corrupt.

You might see if this says anything
interesting:

analyze /rms TCPIP$HOST

The easy way out might be to toss (or at
least hide) the old file, and make and
populate a fresh one. I'd guess that
SYS$MANAGER:TCPIP$CONFIG.COM would know how
to create a new one (and help to populate
it). Or, if you have another, healthier one
on another VMS system, then steal a copy.
Joseph Bianco
Occasional Advisor

Re: TCPIP SHOW HOST Problem

Steven,

I did the anal/rms tcip$host and no problems were reported. The "%LIB-E-KEYNOTFOU, key not found in tree" is what I am concerned about.

Joseph
John Gillings
Honored Contributor

Re: TCPIP SHOW HOST Problem

Joseph,

An ACCVIO from any system provided command or utility is, by definition, a bug. Please log a case with your local customer support centre.

Even if Steven's suggestion that it's due to file corruption (which seems reasonable to me), it's still a bug. If that's the case the utility should report it as such.

FWIW, KEYNOTFOU is from the LIB$*TREE* routines. Most likely reason is the utility uses an in-memory tree to build a data structure which can then be searched. Something wrong with the data files has broken an assumption about what keys should be present.

Bottom line... log a case
A crucible of informative mistakes
Hoff
Honored Contributor

Re: TCPIP SHOW HOST Problem

Would this be related to this posting from a year back?

http://h30499.www3.hp.com/t5/Networking/TCPIP-SHOW-HOST-causes-register-dump/m-p/4559675#M8895


Assuming you have access, apply the current patch, and then call HP support.

Shriniketan Bhagwat
Trusted Contributor

Re: TCPIP SHOW HOST Problem

Hi,

The online help explains the error as below.

$ help/mess KEYNOTFOU


KEYNOTFOU, key not found in tree

Facility: LIB, Library Facility

Explanation: The specified key is not found in the tree. One cause of this
error is when the LIB$FIND_IMAGE_SYMBOL call is unable to
locate the specified symbol in the specified image.

User Action: Check for a missing or erroneous symbol name specification in
a LIB$FIND_IMAGE_SYMBOL call.

Looks like the issue is caused by the LIB$FIND_IMAGE_SYMBOL call as explained above. It may be the issues with the TCPIP.

Regards,
Ketan
H.Becker
Honored Contributor

Re: TCPIP SHOW HOST Problem

>>>
Explanation: The specified key is not found in the tree. One cause of this error is when the LIB$FIND_IMAGE_SYMBOL call is unable to
locate the specified symbol in the specified image.

User Action: Check for a missing or erroneous symbol name specification in a LIB$FIND_IMAGE_SYMBOL call.
<<<

Which means, that there is a mismatch in the main/shareable image and the one activated by lib$fis. The latter does not contain the wanted symbol. This may happen when images from different versions are mixed (or logicals are pointing to these incompatible images). This can happen because there is no and there can not be any VMS supplied match control for lib$fis.

And no, the "user" can't check for the symbol, the programmer has to make sure to find the right image and symbol.
Steven Schweda
Honored Contributor

Re: TCPIP SHOW HOST Problem

> Which means, that there is a mismatch [...]

Or, the fellow who wrote the TCPIP code
thought that KEYNOTFOU would be a good code
to use for some purpose which had no
connection with LIB$FIND_IMAGE_SYMBOL.
Without more information (like the relevant
source code, for example), it's hard to know
much.
H.Becker
Honored Contributor

Re: TCPIP SHOW HOST Problem

There is a lib$fis in the code:
$ tcpip show version

HP TCP/IP Services for OpenVMS Alpha Version V5.6
on an AlphaServer 400 4/233 running OpenVMS V8.3

$ pipe xpd sys$system:tcpip$ucp.exe |search sys$input lib$
offset 0x1440 maps to LIB$GET_CURRENT_INVO_CONTEXT, type is procedure
offset 0x1230 maps to LIB$SHOW_VM_ZONE, type is procedure
offset 0x9e0 maps to LIB$GETSYI, type is procedure
offset 0x9d0 maps to LIB$GETJPI, type is procedure
offset 0x9c0 maps to LIB$GETDVI, type is procedure
offset 0x4c0 maps to LIB$FREE_VM, type is procedure
offset 0x4d0 maps to LIB$GET_VM, type is procedure
offset 0x470 maps to LIB$SHOW_VM, type is procedure
offset 0x460 maps to LIB$SPAWN, type is procedure
offset 0x430 maps to LIB$SIG_TO_RET, type is procedure
offset 0x320 maps to LIB$PUT_OUTPUT, type is procedure
offset 0x2f0 maps to LIB$MATCH_COND, type is procedure
offset 0x250 maps to LIB$GET_INPUT, type is procedure
offset 0xb70 maps to LIB$GET_FOREIGN, type is procedure
offset 0xf10 maps to LIB$FIND_IMAGE_SYMBOL, type is procedure
offset 0xf50 maps to LIB$CREATE_DIR, type is procedure
offset 0xd0 maps to LIB$SET_SYMBOL, type is procedure
offset 0x410 maps to LIB$SIGNAL, type is procedure
offset 0xb60 maps to LIB$EMUL, type is procedure
offset 0x190 maps to LIB$GET_EF, type is procedure
offset 0xa20 maps to LIB$ADDX, type is procedure
$

A $ set watch file/cla=major may help to find out more.
Ian Miller.
Honored Contributor

Re: TCPIP SHOW HOST Problem

the host file is indexed by node name

Has there been changes in node names?
____________________
Purely Personal Opinion