Robert
I've send you a file which summarises the search order issue.
You'll see from the end of the document that not everything was clear but
this is "par for the course" in regard to CS IP documentation.
-
I have a tentative recommendation which goes as follows:
- Set up a resolver procedure.
You necessarily have a resolver procedure running and, if you haven't
created your own, it uses a well-hidden procedure called not "RESOLVER", as
you might be sure it must be, but IEESYSAS, a general purpose procedure
which can be used whenever a DD-statement need not be added to the EXEC
statement.
- Be sure to specify COMMONSEARCH in your "resolver", SETUP, file.
If you are using a local file for name to address translation, you can use
the sensible format as defined in the CS IP Configuration Guide. section
1.5.4.4, "Creating ETC.IPNODES and /etc/ipnodes".
- I am assuming you don't want to be too complicated for the moment so
define a "client[1] data set" using the GLOBALTCPIPDATA statement in your
"resolver", SETUP, file.
Note that, when you use the GLOBALTCPIPDATA statement, all parameters which
relate to using a name server necessarily reside in the specified file. This
becomes important only when you start getting clever and try to concatenate
this data set with another data set.
- Similarly assuming you don't want to be too complicated for the moment and
that you are defining name to address relationships in a local file rather
than using the name server system - and you have specified COMMONSEARCH as I
suggested above, you should define the name to address data set using the
GLOBALIPNODES statement in your "resolver", SETUP, file.
You may have noticed that Sheila mentions using the DEFAULTIPNODES statement
in an earlier post. This is similar to the GLOBALIPNODES statement but comes
last in the search order rather than first.
-
That deals with the "Base resolver configuration file" and the "Local host
table".
In order to keep the remaining files as simple as possible, given that you
are unlikely to need to change the supplied files, simply create
TCPIP.ETC.PROTO and TCPIP.ETC.SERVICES files so that they can be dynamically
allocated by file name - one of the features of Communications Server (CS)
IP which reveals its VM heritage.
You can probably simply use the internal version of the translate table.
Chris Mason
[1] "Client" here refers to the relationship of CS IP-related address
spaces, the "client" address spaces, which rely on the main CS IP address
space, the "server" address space. The file is otherwise referred to as the
TCPIP.DATA file which again reflects the VM heritage.
----- Original Message -----
From: "Johnston, Robert E" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: <IBM-MAIN@BAMA.UA.EDU>
Sent: Friday, September 07, 2007 11:24 PM
Subject: Re: CA to IBM TCP Conversion
...
All these APIs and search orders and such make my head spin!
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
