Moribund or not, you're paying for support. Why not use it? My guess
is that you're using the SAS/C resolver and you should switch to the
IBM resolver. Contact SAS tech support or just read the manual to
see how to do that.

In article 
<2055c4ebc2b05442853ca436c40652851bcd5...@nwb-exchange.microfocus.com> you 
wrote:
> Chris -
> Thanks for the response. Since I posted I have tried running hometest,
> telnet, with the trace and they do "gethostbyname()" without problems,
> so I am inclined to think the problem lies with the SAS/C runtime.
> Unfortunately SAS/C is no longer marketed and is basically a bit
> moribund, so I don't expect any help from that quarter. 

> By "host name" I indeed meant the system name; it turns out that fully
> qualifying that with the domain circumvents the problem, so I suggested
> that to the customer as a work-around. I will check-out the IBMTCP-L
> list, however.

> Cheers
> -Robin

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Chris Mason
> Sent: 27 May 2011 15:02
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Problem with resolving own host name

> Robin

> I see you have not had a response to this.

> Please be aware that the greatest concentration of IP-based expertise is
> in 
> IBMTCP-L:

> For IBMTCP-L subscribe / signoff / archive access instructions, send
> email to 
> lists...@vm.marist.edu with the message: INFO IBMTCP-L

> > Turning on the resolver trace shows the host name getting resolved 
> correctly, it just doesn't reach the application.

> > We are using SAS/C R750 compiler and runtime.

> Given that the resolver trace is as expected, it looks like a problem at
> the 
> level of the API. What do SAS "C R370" say the problem might be?

> > We have an application on z/OS 1.11 that reads in its unqualified host
> name 
> from a config member

> Incidentally, just to be clear, this "unqualified host name from a
> config 
> member" is presumably a gethostname() call so that the string returned
> is the 
> typically single token corresponding to what is specified in the
> generically 
> named TCPIP.DATA data set HOSTNAME parameter, default the VMCF 
> parameter name or, failing that, the MVS system name.

> Chris Mason

> On Thu, 26 May 2011 17:00:32 +0100, Robin Atwood 
> <robin.atw...@microfocus.com> wrote:

> >We have an application on z/OS 1.11 that reads in its unqualified host
> >name from a config member and resolves it via an external DNS server by
> >calling "gethostbyname()". This works as expected if the TCPIP.DATA
> >config contains a "DOMAINORIGIN" statement. If we change the
> >DOMAINORIGIN to a "SEARCH" statement, specifying our domain name first
> >in the list, gethostbyname returns null. This was first reported by a
> >customer and I can it duplicate it here. Turning on the resolver trace
> >shows the host name getting resolved correctly, it just doesn't reach
> >the application. Fully qualifying the host name in the config member
> >gives the right result. We are using SAS/C R750 compiler and runtime.
> >
> >TIA
> >--
> >Robin Atwood
> This message has been scanned by MailController - portal1.mailcontroller.co.uk

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com           (919) 531-5637                Cary, NC 27513

----------------------------------------------------------------------
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

Reply via email to