Hello Wirt,

> As I've mentioned several times before here on the list, the trick that we
> adopt here is that we run JINETD in the B queue, but this solution has not 
> been
> much appreciated by James Hoffmeister. Unfortunately, the only thing to
> recommend doing this is that it works. That, and the fact that we've seen 
> no
> downside to doing this.

Spelled "Hofmeister", only 1 "f" please and yes, I am always careful to 
"not" offer solutions that can have negative results.  In this case you need 
to keep in mind that part of TCP runs on user stacks and TCP implements 
semaphore locking to assure the accuracy of network data structures; hence 
the solution to setting the INETD priority implemented in INT patches as per 
SR 8606156115 found in INTFDX2 6.0, INTFDX3 6.5, INTGD33 7.0 & base 7.5 
release.

I don't recommend running INETD with ";pri=bs" because I have read the 
memory dumps with semaphore locking issues and worked with the labs to 
implement the SR 8606156115 solution.

The reason I asked about what the contents of the "JINETD" job is to also 
look to see if "-l" logging is enabled.  The logging option does a reverse 
IP to Name lookup request of the DNS and if you have a mal-functioning or 
"bogus/invalid" DNS server configured, many of the same errors can be seen; 
a very common symptom is "slow" performance at initial connection for as 
long as 60 seconds and as users give up ([x] the window) the error messages 
reported in this thread may be seen.

The warranty and liability expired as you read this message.
If the above breaks your system, it's yours and you keep both pieces.

Regards,
James Hofmeister
Email: <first>.<last>@hp.com
Hewlett Packard - Global Solutions Engineering (WTEC)
P.S. My Ideals are my own, not necessarily my employers. 

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *