I apologize for not making the full configuration available, although all the pointers suggested were checked and confirmed as valid (active interface, hosts table, service ports, default route, etc).
For now we'll settle with the workaround of using the system name instead of localhost. I really appreciate all your help.
--
Saludos
Antonio Salazar
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Tuesday, February 16, 2010 12:27 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Can a DDMF point to localhost?
Although the suggestions may have been followed, for example by
answering the questions, they were not posted in response.? If they
helped to get a working solution but not the desired outcome,
perhaps posting the responses would assist someone to assist in
reaching the desired outcome.?
The 127.0.0.1 should be defined as a TCP\IP "loopback"
/Interface/ *and* as a Host Table Table Entry [ADDTCPHTE; although
they should exist by default.?] with LOCALHOST as the host name [for
that 127.0.0.1 address]. Nothing but a default route, the
*DFTROUTE, should be required to be defined in the TCP\IP routes.
http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/topic/cl/addtcphte.htm
http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/topic/rzaku/rzakupingloopback.htm
http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/topic/rzaku/rzakupingloopbacknav.htm
In a test CRTDDMF on a v5r3 system, having specified the
RMTLOCNAME(localhost *IP) seems to have that value resolved to the
host name anyhow, after its first access; i.e. DSPFD or DSPDDMF
after DSPPFM or OPNDBF show that the remote location name since
became the domain host name. As such, I guess just specifying the
host name directly would suffice. But then any change to either the
domain or the IP address, that would require changing\correcting the
DDM file definitions as well.? Very odd, as I would expect the
value of localhost to remain unresolved, especially since an "open"
is not a CHGDDMF which apparently had effectively transpired; maybe
a defect?
Regards, Chuck
Jose Antonio Salazar Montenegro wrote:
I went through all your helpful suggestions and links, and found
a way to make it work.
It turns out that a 127.0.0.1 DDMF fails on use with CPE3425,
without previous messages, something that was meant the service
was down or the port was wrong, which they aren't:
CRTDDMF FILE(QTEMP/$DDMF)
RMTFILE(S47CYFILES/CRFCOM)
RMTLOCNAME('127.0.0.1' *IP)
But using the 'real' IP works fine:
CRTDDMF FILE(QTEMP/$DDMF)
RMTFILE(S47CYFILES/CRFCOM)
RMTLOCNAME('1.2.3.4' *IP)
I really don't know if this is equivalent to using 127.0.0.1 or
if it's doing a round trip around our net. Either way, it would
be better if the DDMFs pointed to localhost instead of a specific
IP address.
¿Could it be a routing issue? Neither 127.0.0.1 or 1.2.3.4 appear
in the TCP/IP routing table.
midrange.com
