Kurt Well, I did say the "resolver" was mysterious!
I discovered some evidence barely supporting my guess and some evidence that doesn't at all support my guess - but just may simply be deficient. In the z/OS Communications Sever IP Configuration Guide, we find the following: <quote> 2.5.5 Managing the resolver address space The resolver start procedure name is used with the following MVS system commands to manage the resolver address space: - ... - Modify (F) Use the MODIFY command to dynamically change resolver setup statements, to update the use of TCPIP.DATA statements, or to update the use of local host and services tables. </quote> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B3B0/2.5.5 Squirming, as I am obliged always to do, at the policy of the IBM manual authors never knowingly to leave any infinitive unsplit,[1] we discover that, supposedly, "services" tables are included along with "local host tables" as well as the "resolver setup" data set and the one or two[2] generically named TCPIP.DATA data sets. What's a bit of a puzzle here is that there are three types of name to number lookup involved with sockets programs, not just two: - name (strings of concatenated tokens) to IP address and vice versa ("ETC.IPNODES" for example) - service token to port number and vice versa ("ETC.SERVICES" for example) - protocol token to protocol number and vice versa ("ETC.PROTO" for example) So what about the "protocol numbers"? How come they don't get a mention? Surely they are handled in just the same manner as the "service/port numbers". Doubt creeps in! However, now you'd expect that the kind manual authors, having pointed out that the MODIFY command is relevant, would expand on the matter in the z/OS Communications Sever IP System Administrator's Commands, wouldn't you? Well, you'd be in for a disappointment, I'm afraid! Here is what is said: <quote> 1.8.7 MODIFY command: Resolver address space You can refresh the resolver address space from the operator console using the MODIFY command. Issue the REFRESH command to refresh the resolver address space and the DISPLAY command to display the current values of the resolver setup statements. Issue the FLUSH command to delete the contents of the resolver cache. You can also reset the current z/OS knowledge of name server capabilities by issuing the REFRESH command. ... REFRESH Causes applications to have their TCPIP.DATA information updated on their next resolver request after the refresh occurs, including local host tables (for example, etc/hosts, etc/ipnodes, HOSTS.SITEINFO, HOSTS.ADDRINFO, or ETC.IPNODES information). </quote> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1c2a0/1.8.7 Oh dear me, nary a word about "services tables", let alone "protocol tables"! So, as I said, just a guess! - If you have any sort of sandbox facility available, or even on a production system if you contrive to create a "services table" data set specific to just own testing userid, you could write a trivial REXX sockets program with just a GETSERVBYNAME call in it. Well, nothing if not conscientious, I decided to be sure that the REXX API catered for this suggestion and - what do you know? - what you need is provided as an example: <quote> /* REXX EZARXR17 */ /* * This sample demonstrates the use of the GETSERVBYNAME * socket command. */ if perror(socket("INITIALIZE","MYSET01"),"INITIALIZE") = 0, then do src = socket("GETSERVBYNAME","FTP"); Say "The FTP service is assigned "SUBWORD(src,2); end; src = perror(socket("TERMINATE","MYSET01"),"TERMINATE"); exit 0; /* This routine returns -1 if the first word if arg 1 is not zero */ perror: if word(arg(1),1) = 0 then return 0; else Say arg(2) "Error : "arg(1); return -1; </quote> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1D490/3.5.2.18 So you can experiment with this in order to see whether your private "services table" simple needs to be edited to record a change or whether a MODIFY RESOLVER,REFRESH command is needed. And do let us all know. - [1] Actually the score is 1 out of 3, but it feels like 3 out of 3! [2] Potentially two if the GLOBALTCPIPDATA "resolver setup" statement is used. - Chris Mason On Wed, 26 Oct 2011 13:55:57 -0500, Chris Mason <[email protected]> wrote: >Kurt > >> Thanks to any and all who consider my question. >> Thanks for any help anyone is willing to offer. > >You don't have to be so effusive. All we ask is that you donate something >significant to our favourite charity! > >> Can the TCPIP.ETC.SERVICES file be changed at will ... > >I'm going to guess that, this being a file associated with the sometimes >mysterious "resolver" function, if you can't immediately see any change >reflected in the translation of a text string such as "http" being converted >to the number 80 at the time your program issues the relevant getservbyname() >call - typically during the initialisation phase of the program - you should >"refresh" your resolver address space with the following command: > >MODIFY resolver,REFRESH > >where "resolver" is the name of your "resolver" address space, typically >"RESOLVER", of course. > >Now, I have to go to dinner but I'll sniff around the manuals later in order >to see if there's something definitively stated somewhere. > >Incidentally, the greatest concentration of expertise with the IP component of >z/OS Communications Server is to be found here: > >For IBMTCP-L subscribe / signoff / archive access instructions, send email to >[email protected] with the message: INFO IBMTCP-L > >Another incidentally: "How to refresh ETC.SERVICES" would have been a subject >which rather more closely "hit the spot" don't you think? > >Chris Mason > >On Wed, 26 Oct 2011 11:14:53 -0700, Kurt Eastwood <[email protected]> wrote: > >>Hello, >> >>Thanks to any and all who consider my question. >> >>Can the TCPIP.ETC.SERVICES file be changed at will or are there special >>considerations for changing this file , such as task usage, back up, etc that >>must be taken into account before changing this file? >> >>Can anyone give me a brief explanation when and how this file is used? >> >>Thanks for any help anyone is willing to offer. >> >>Kurt ---------------------------------------------------------------------- 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
