Ravi Here's the first point regarding lists rather than your specific problem:
If you browse the archives http://alabamamaps.ua.edu/archives/ibm-main.html you will note that the post which initiates a topic or "thread" is not adorned with an initial "Re:" but that all subsequent posts relating to that thread are. This convention enables the list subscriber to be aware of when a new thread is being begun and avoids the small panic which might afflict some that a topic to which they would have liked to participate appears already to have run some of its course. It is evident once I got into this post that it is indeed initiating a new thread. - Now to what I can say about your problem: inet_addr() is a C call which is used to convert an IP address in character format with character numbers and full stops - known as "periods" in some parts of the world - into an internal format --- in network byte order, as I see from my notes on socket calls. I can see from the rest of your post that you are using IPv4 so I don't need to worry about IPv6. I don't know the internal workings of SMTP all that well so I am now going to guess that "LOCALHOST" is supposed to map to an IP address which is used for "loopback" purposes and that it should map to typically address 127.0.0.1. I am going to continue guessing and make some assumptions. It is normal for all "client" logic to take the character string which is supposed to be the identification of the "server" and first assume it is the external form of the IP address in character numbers and note optionally - "There's not many people know that!"[1] - full stops. With this assumption, the inet_addr() call is used in order to convert the IP address to the internal format for use in the bind() structure, used in the connect() call if TCP is being used - that's "TCP" the transport protocol not some lazy reference to IP and its associated protocols as I have seen it used in this and other lists. If the inet_addr() call fails, it is typically the case that it is now assumed a name has been supplied and the character string is input to the gethostbyname() C call. The gethostbyname() call uses the resolver function to convert the name to, in the general case, a list of IP addresses. This too can fail of course. It would seem that, when the gethostbyname() call fails, SMTP actually reports the earlier failure of the inet_addr() call - which it is entirely logically correct to do since the gethostbyname() call having failed, how can the SMTP logic possibly tell what the unusable character string was intended to be in the mind of the systems programmer who has messed it all up? Actually it could analyse the character string further in order to make a more accurate guess at what was wrong but it appears the writers of the SMTP logic were just not feeling that kind to their errant users! For example, they could have checked the first character and, if it was a number, assumed that it was the inet_addr() which had failed to convert what was supposed to be an IP address and, if it was not a number, assumed that the gethostbyname() which had failed to resolve a name. So, what you might like to look at is whether LOCALHOST can be resolved to a "loopback" IP address such as 127.0.0.1 and if not, ensure that it can be and then see if that fixes your problem. An example of defining LOCALHOST as a name is the following statement in a local name and address file in "ipnodes" format: 127.0.0.1 localhost Rather obvious really. However you will use this file of this type only if you have configured your resolver with the COMMONSEARCH statement and you have LOOKUP LOCAL (or LOOKUP DNS LOCAL or LOOKUP LOCAL DNS) in the generically named TCPIP.DATA file used by the resolver. If you are using a name server, the name server really ought to be offering the mapping of LOCALHOST to 127.0.0.1 and that would appear not to be happening. - As a matter of interest, what do you mean by "tcp forum"? The list which *actively* supports questions relating to the IP component of z/OS Communications Server is the IBMTCP-L list: For IBMTCP-L subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO IBMTCP-L Also, for want of another list these days, the IBMTCP-L list supports questions relating to the SNA component of z/OS Communications Server. - Regarding the archives, the problem as I suppose it is was discussed in a thread initiated by Glen Gasior in this IBM-MAIN list in February this year under the Subject "TSO PING LOOPBACK" but LOCALHOST only cropped up in the discussion of the original problem so I can see how you wouldn't have found it. - Chris Mason - [1] If you Google that, you'll find that it is - incorrectly - assumed to be "Not a lot of people know that." On Thu, 18 Nov 2010 03:21:52 -0600, Ravi Kumar <gaur.ravi2...@gmail.com> wrote: >Before I talk to SAS thought to cross post here.. > >I am exploiting mailing service using SAS however on particular lpar only >it seems to be not working ..below is my JCL. > >//SENDMAIL EXEC SASMSTR, >// OPTIONS='EMAILSYS=SMTP EMAILHOST=xxx.xxx.xxx.xxx' >//SYSIN DD * > Filename emp email > From='xx...@xxxx.com' > To='xxxx....@xxxx.com' > Subject='TEST' > Attach ='xxxxx.TEMPFTP.TEXT'; > Data _Null_ ; > File emp; > put ; > run; > >I have checked the SMTP Mailer address in SMTP Config >EZA5348I IP Mailer Address : xxx.xxx.xxx.xxx ==same as used >in job. > >I get below error :- > >ERROR: Unable to connect to SMTP server. >ERROR: Unable to connect to SMTP server. >ERROR: Unable to connect to SMTP server. >ERROR: inet_addr failed, cannot convert address 'LOCALHOST'. >ERROR: inet_addr failed, cannot convert address 'LOCALHOST'. >ERROR: inet_addr failed, cannot convert address 'LOCALHOST'. > > >Now not able to crack it down to find why it's not able to resolve the SMTP >mailing server address... > >One of the diagnostic step I took was to start the packet trace on address >= xxx.xxx.xxx.xxx and port 25(smtp) however seems my job when ran could not >even hit this hence nothing was captured in the Packet tracing... > >Does anyone has any kind of thought or ideas to crack it down ...Thanks > > > > > > > >-------------------------------------------------------------------------- - >Note ** I have searched in archive and also cross post to tcp forum ** also >did google however when listed doesn't match with solution for me ** >-------------------------------------------------------------------------- ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
