🚀 go-pugleaf

> Now, we did work around a bug in the RT's hc compiler (hc 1.4r) that 
> was causing bogus names (that it should have rejected) to come out as 
> ``indeterminate''.  Might that be a possible reason why you get some of 
> your ``indeterminate'' answers?  

It very well could be.  I used hc1.4 to compile the whole ATK.

> And do you have the HardHostValidation flag off, so that all hard failures
> (``bad'') map to soft ones (``indeterminate'')?  (This is a fix not in any 
> official patch, yet.)
I put 
	AMS_HardHostValidationErrors: no
into our AndrewSetup file which explains why my errors were softened.

I'm really confused why Messages can't pickup on the use of the Name
Resolver.  I know we have it installed and I thought I've been using it
in other programs for some time now (telnet, finger, etc).  Just to
verify that  ATK is square on the Name Resolver, I checked:

% cd ${ANDREWDIR}/config
% grep RESOLVER *
allsys.h:#define RESOLVER_ENV	1
allsys.mcr:#ifdef RESOLVER_ENV
allsys.mcr:#else RESOLVER_ENV
allsys.mcr:#endif RESOLVER_ENV
allsys.mcr.orig:#ifdef RESOLVER_ENV
allsys.mcr.orig:#else RESOLVER_ENV
allsys.mcr.orig:#endif RESOLVER_ENV

To make absolutely sure that this was really affecting compiles such as
valhost.test, I issued a cc -E and then searched for text wich valhost.c
will only include if RESOLVER_ENV is turned on.  I found the text.

The only thing I can conclude is:
a)  our system administrator mucked with my machine and accidentally
turned off the name resolver.  (Do you know of a quick, non-ATK, way of
checking for the Name Resolver?)
b)  ATK is somehow, someway, subtly not connecting to the Name Resolver
library routines.

   - Anthony