× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I'm confused, too. Not that I know this stuff anywhere near as well as you, Rob, and Simon, but something is amiss.

My Test box (the one that had the original issue) has nothing in it except internal (10.) addresses and the loopback. Same for the Production box.
The Test box has:

Change TCP/IP Domain (CHGTCPDMN)

Host name . . . . . . . . . . . HOSTNAME 'bnwbackup'
Domain name . . . . . . . . . . DMNNAME 'bnw.com'
Domain search list . . . . . . . DMNSCHLIST *DFT
Host name search priority . . . HOSTSCHPTY *REMOTE
Domain name server: INTNETADR
Internet address . . . . . . . *NONE
Port . . . . . . . . . . . . . . PORT 53
Protocol . . . . . . . . . . . . PROTOCOL *UDP
Initial domain name server . . . INLDMNSVR *FIRST
Domain name server retry: DMNSVRRTY
Number of retries . . . . . . 2
Time interval . . . . . . . . 2

The production box has:

Change TCP/IP Domain (CHGTCPDMN)

Host name . . . . . . . . . . . HOSTNAME 'BNW400'
Domain name . . . . . . . . . . DMNNAME 'bnw.com'
Domain search list . . . . . . . DMNSCHLIST *DFT
Host name search priority . . . HOSTSCHPTY *REMOTE
Domain name server: INTNETADR
Internet address . . . . . . . '10.0.0.16'
'10.0.0.14'
Port . . . . . . . . . . . . . . PORT 53
Protocol . . . . . . . . . . . . PROTOCOL *UDP
Initial domain name server . . . INLDMNSVR *FIRST
Domain name server retry: DMNSVRRTY
Number of retries . . . . . . 2
Time interval . . . . . . . . 2

Except for the HOSTNAME and INTNETADR parameters they are identical. Earlier I set the production box's INTNETADR value to *None; ran Ping google.com. It failed so I set the INTNETADR value back as you see it.

I did the same ping from the Test box, and it verified.

To answer Rob's earlier question, too, the NSLOOKUP PTF.BOULDER.IBM.COM on the Test box yielded:

Server: bnwbackup.bnw.com
Address: 0.0.0.0
Server bnwbackup.bnw.com can not find host PTF.BOULDER.IBM.COM.
No response from server.
Press ENTER to end terminal session.

The NSLOOKUP PTF.BOULDER.IBM.COM on the Production box yielded:

Can not find server name for address 10.0.0.16: Host or domain does not exist
Can not find server name for address 10.0.0.14: Host or domain does not exist
Server: BNW400.bnw.com
Address: 0.0.0.0
Server BNW400.bnw.com can not find host PTF.BOULDER.IBM.COM.
No response from server.
Press ENTER to end terminal session.

In brief, the Test boxed succeeded (with the above settings) with both the ping and ftp to PTF.BOULDER.IBM.COM.

These two boxes sit in the same room on the same network about 3-6 inches apart on the same table.
I'm happy that the ftp from the System i finally worked. I'm sad that something is apparently flummoxed and that I have no idea where.

Jerry C. Adams
IBM System i Programmer/Analyst
--
B&W Wholesale
office: 615-995-7024
email: jerry@xxxxxxxxxxxxxxx


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Tuesday, August 25, 2009 2:36 PM
To: Midrange Systems Technical Discussion
Subject: Re: PTF FTP Download Problem

I'm confused. If you have the INTNETADR parameter of CFGTCP, opt 12 set
to *NONE, how is it looking up the IP address for ptf.boulder.ibm.com?
That doesn't make any sense.

That's how I knew you had a host table entry before -- you had *NONE for
the DNS server, therefore there must've been a host table entry to
translate the name to a number. No other way to translate a name to a
number.

Now you say you deleted the host table entry, left it at *NONE, and it
works? That makes no sense.


Jerry Adams wrote:
Well, Scott (surprise, surprise) nailed it. There was a host table
entry for Boulder at 207.whatever. Whacked that and got the PTF
fine. Did not make any changes to the DNS (CFGTCP #12) entries;
i.e., it is still *None.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.