On Mon, 2 Apr 2001, Craig A. Berry wrote:
> At 02:39 PM 4/2/2001 -0700, Peter Prymmer wrote:
>
> >It does not look like a bug to me since it is trying to find the FQDN at
> >the point in question:
>
> but as far as I can tell, UCX$INET_HOST_NAME is not and never was something
> defined by UCX, so the first line of the section you quote is probably a noop.
It might be a noop or it might be compatible with UCX 1.0 or some other
weird version/configuration. I can say that it was not dreamt up at
random and placed into configure.com. It was more likely copied from
another DCL script that probed tcp/ip stacks in the days of yore. Since
it certianly does not seem widespread or popular I'd be happy to remove it
if you can think of a reason to take it out. I cannot think of a reason
to remove it at this time and the "backward compatability" argument is in
favor of retaining it at this time.
> >$ IF myhostname.eqs."" THEN myhostname = F$TRNLNM("UCX$INET_HOST_NAME")
> >$ IF myhostname.eqs."".and. -
> > F$TRNLNM("UCX$INET_HOST") .nes. "" .and. -
> > F$TRNLNM("UCX$INET_DOMAIN") .nes. "" THEN -
> > myhostname = F$TRNLNM("UCX$INET_HOST") + "." + F$TRNLNM("UCX$INET_DOMAIN")
> >
> >So it ought to drop through to the values that your system has (does it
> >not do so?).
>
> Ah, yes, it apparently does, but since UCX$INET_HOST translates to "unknown"
> on my system, I thought there was something missing in configure.com. It
> turned out there is something missing in my system configuration, though for
> the life of me I can't figure out what. I'm using the DHCP client feature,
> so perhaps that keeps it from figuring out who it is.
Odd. I've used DHCP clients on Windows and never had any trouble with the
node name changing out from under me. I have not used DHCP on VMS though.
Try running @SYS$MANAGER:TCPIP$CONFIG and see that the "Core environment"
is set up "correctly". It is customary to set the nodename to the same as
f$getsyi("SCSNODE") [or f$trnlnm("SYS$NODE") if you're running DECnet] but
I don't think that that is _necessary_. I have wanted to try the
experiment of giving a VMS box a different UCX nodename from the DECnet or
SCSNODE name but I do not have access to so many machines that I can goof
around with such stuff unfortunately.
> We could probably delete the line in configure.com with UCX$INET_HOST_NAME,
> but it doesn't look like having it there actually harms anything.
I don't think that it does. I'd appreciate hearing from someone who knows
otherwise.
> >Clearly something like TCPIP$* would be more recent than UCX 4.x. We
> >should probably add some checks for them.
>
> Since the UCX$* logicals are still present in TCP/IP 5.1, I think we can
> rely on their existence for the forseeable future.
I was not proposing removing the UCX$* logicals (BTW my copy of my post to
vmsperl had a very mangled patch - I am not sure it made it throug
cleanly). I was merely proposing that we add checks for the TCPIP$*
logical names as a backup check in case the UCX$* ones disappear in the
future. I thought that perhaps one day Compaq could switch everything
over to TCPIP$* and no longer set nor use UCX$* (this seems admittedly
unlikely, but who knows?).
BTW I've found two solutions to the XS::Typemap problem on VMS - more in a
bit.
Peter Prymmer
