Frank > Kind of a rambling message.
One way to unscramble this to some extent is to separate any discussion of the "resolver directives" file, of which one manifestation is the file referenced by the SYSTCPD DD-statement from discussion of the FTP parameter file. They belong in two different camps and, if you happen to use the SYSTCPD DD-statement, come together only in the JCL used to initiate your batch FTP jobs. Having read about your HOSTS.LOCAL stuff, I was shocked to see you actually had a customised resolver procedure. But, from what you say, it seems your local Homer Simpson is in charge of it! COMMONSEARCH is one of the most neuron-free no-brainers there is! Incidentally, since you are in a purely test environment, there are two reasons for dropping the DNS from the LOOKUP statement. One is that you definitely avoid name to address translations in the name server which I assume would always give you production targets. The other is to know for sure - by means of lookup failures while testing - what names the jobs you are testing need. I'm not at all clear as to why you bothered to show the file referenced by the DEFAULTTCPIPDATA statement. As you can see from the trace nothing from it is used. It is only when you use the GLOBALTCPIPDATA file that two files can be used and parameters merged in order to create the set of parameters used - and even then there are restrictions - but LOOKUP isn't one of the restricted parameters. > If we need to have a permanent hosts file in the future I will recommend COMMONSEARCH. In case you are stopped, make sure the gun is licensed! Horse's heads can be messy but they have their uses! Have you seen Syriana yet? I saw it on one of the Belgian channels a couple of days ago. > It's interesting (to me, anyway) to see the result of the resolver trace: This is another no-brainer when you want to be sure you understand what the system is doing for you regarding name resolution. > I am curious what affect changing DATASETPREFIX in the system TCP.DATA file would do. On the tin we read: <quote> Use the DATASETPREFIX statement to set the high-level qualifier for the dynamic allocation of data sets in TCP/IP. </quote> The key words here are "dynamic allocation". The z/OS Communications Server (CS) IP component has a long and distinguished history and can trace its ancestry back to the "TCP/IP for VM" product - the descendants of which are still among us. Because of the VM DNA, there is/has been a strong tendency towards the "dynamic allocation" of files mimicking the way files are naturally allocated in CMS. The generic name for the "resolver directives" file as found in the manuals is evidence of this; TCPIP.DATA stared life as TCPIP DATA in a CMS context. So, regarding knowing whether or not a filename uses the hlq specified by the DATASETPREFIX parameter, if it's allocated dynamically, it's a candidate. This is what one can find under "Dynamic data set allocation", "Configuration data set naming conventions", "Understanding search orders of configuration information" in Chapter 2, "IP configuration overview" in the CS Configuration Guide: <quote> - hlq TCP/IP is distributed with a default high-level qualifier (HLQ) of TCPIP. To override the default HLQ used by dynamic data set allocation, specify the DATASETPREFIX statement in the TCPIP.DATA configuration file. For most configuration files, the DATASETPREFIX value is used as the high-level qualifier of the data set name in the last step in the search order. Note that the DATASETPREFIX value is not used as the high-level qualifier of the data set name used as the last step in the search order for the PROFILE.TCPIP and TCPIP.DATA configuration files. </quote> > But I can't find an authoritative list of all of the dataset names that are resolved by the TCPIP DATASETPREFIX. I imagine that the later Table 3, "TCP/IP configuration data sets", under "TCP/IP configuration data sets", is intended to be the definitive list of CS IP configuration files which - when "dynamically allocated" - can use the "hlq" value specified by the DATASETPREFIX parameter for the address space. I guess it helps when looking for something that you are sure it must be there! I know that, when I used to teach TCP/IP for MVS I referred to the - at the time - massively reduced version of this table. However, given your problem - shared by all users of what is now the CS IP component and was "TCP/IP for MVS" plagued, one can say, by the VM inheritance, this text from later in the "Dynamic data set allocation" section might interest you as an "I feel your pain and here's what you can do about it": <quote> Following are some of the data sets that are only dynamically allocated by TCP/IP in a configuration file search order (you cannot specify them with DD statements in JCL): ETC.PROTO ETC.RPC HOSTS.ADDRINFO HOSTS.SITEINFO SRVRFTP.TCPCHBIN SRVRFTP.TCPHGBIN SRVRFTP.TCPKJBIN SRVRFTP.TCPSCBIN SRVRFTP.TCPXLBIN STANDARD.TCPCHBIN STANDARD.TCPHGBIN STANDARD.TCPKJBIN STANDARD.TCPSCBIN STANDARD.TCPXLBIN For each of these data sets, the fully qualified name is established by using one of the following values as the data set HLQ: - User ID or job name - DATASETPREFIX value </quote> > Following are some of the data sets that are only dynamically allocated by TCP/IP in a configuration file search order (you cannot specify them with DD statements in JCL): Doesn't this have the subtext "These are the data sets which are still a pain where the sun don't shine!"? So, if you manage to flush out all the other dynamic allocations with DD- statements, you can deal with this residue where necessary. First, I'm assuming the Far Eastern language translate tables are of no concern to you. That eliminates most of the files ending in "BIN" (KJ = Kanji, HG = Hangeul, SC = Simplified Chinese, CH = Traditional Chinese). I believe you need worry about the TCPXLBIN files *only* if you need translation of ASCII to EBCDIC and vice versa which is *not* standard. When you manage to make to your colleague in charge of the resolver setup file an offer which he or she cannot refuse, you need no longer worry about the "HOSTS" files. You'll be using the GLOBALIPNODES or DEFAULTIPNODES statements instead. If you use "Remote Procedure Call" (RPC) I guess you're stuck with ETC.RPC. That just leaves ETC.PROTO, vital for the task of converting the characters "tcp" to 6 and the characters "udp" to 17 and maybe not a great deal more, but I expect having to set up just this one file won't give you sleepless nights - unlike some of the measures you could be taking with that colleague![1] Chris Mason [1] I wonder just how reliable table 3 is. My notes on resolver files indicates that the "services" file, very similar to the "proto" (protocols) file, can be specified with DD-statement SERVICES but that isn't mentioned in Table 3 - although ETC.SERVICES is not specified in that list starting with ETC.PROTO. However - more searching - it is covered under "Resolver configuration files" in the same Chapter 2. It seems you need to keep checking the manual - and, in your case, trying things out - a sigh for my test systems of old ... On Thu, 15 Apr 2010 17:37:21 -0600, Frank Swarbrick <[email protected]> wrote: >A very interesting discussion, and of some relevance to me. For our migration from VSE to z/OS we have a z/OS LPAR set up that will become the production LPAR. We are running many, many, many tests of our batch processing with what will become the production JCL. This posed an interesting obstacle with regard to FTPing of files. Since it's not "real production" we of course don't want to send data to our real production FTP servers. So I figured we could just use a "local hosts" file on z/OS to redirect the production host names to test host names. And here is how I, an applications programmer with no access to update the "system", accomplished this: > >File 'PROD.HOSTS.LOCAL': >HOST : 10.0.11.9 : opsserver23, opsserver23.fb :::: >HOST : 10.0.11.9 : opsserver, opsserver.fb :::: >HOST : 10.1.109.6 : vsu, vsu.fb :::: > >Run TSO MAKESITE HLQ=PROD to create PROD.HOSTS.ADDRINFO and PROD.HOSTS.SITEINFO. > >member FTPDATA in our "include" PROCLIB: >//SYSTCPD DD DISP=SHR,DSN=PROD.APPLIB.PARM(TCPDATA) >//SYSTCPT DD SYSOUT=* > >File 'PROD.APPLIB.PARM(TCPDATA)' >Trace resolver >DatasetPrefix PROD >Search fb >Lookup local dns >NameServer 10.1.103.22 >NameServer 10.29.100.5 >SortList 10.0.201.0/24 > >File 'PROD.ftp.DATA' >SECURE_MECHANISM TLS >SECURE_DATACONN PRIVATE >KEYRING FTPS/ftpsring >NETRCLEVEL 2 >LOGCLIENTERR TRUE >EPSV4 TRUE > >Example of FTP job to be executed: > >//EXECFTP EXEC PGM=FTP,PARM='opsserver23 3443 (EXIT' >// INCLUDE MEMBER=FTPDATA >//SYSPRINT DD SYSOUT=* >//NETRC DD DISP=SHR,DSN=PROD.APPLIB.NETRC(MYUSER) > >Our Resolver setup file was copied exactly from the example TCPIP.SEZAINST (RESSETUP), with only the dataset name itself being changed to fit our site standard. Specifically, the only two "non-comment" lines in it are: >DEFAULTTCPIPDATA('SYS2.PRD1.PARMLIB(TCPDATA)') >NOCOMMONSEARCH > >File 'SYS2.PRD1.PARMLIB(TCPDATA)': >TCPIPJOBNAME TCPIP >HOSTNAME PRD1 >DOMAINORIGIN fb >DATASETPREFIX TCPIP >NAMESERVER 10.1.103.22 >NAMESERVER 10.29.100.5 >RESOLVEVIA UDP >RESOLVERTIMEOUT 1 >RESOLVERUDPRETRIES 4 >ALWAYSWTO NO > >I needed to use my own resolver override file (DD SYSTCPD in the FTP job) so that I could search local before DNS and have PROD (instead of TCPIP) as the HLQ for the HOSTS.* datasets. Should the system TCPIP.DATA file have been changed? Yes; but since this is only temporary I went my way. > >One thing I was disappointed about is that I couldn't use the IPNODES file instead of the HOSTS file; because the resolver setup file has NOCOMMONSEARCH. Oh well. If we need to have a permanent hosts file in the future I will recommend COMMONSEARCH. > >It's interesting (to me, anyway) to see the result of the resolver trace: > >-------------------------------------------------------------------- >Resolver Trace Initialization Complete -> 2010/04/15 17:28:23.725580 > >res_init Resolver values: > Global Tcp/Ip Dataset = None > Default Tcp/Ip Dataset = SYS2.PRD1.PARMLIB(TCPDATA) > Local Tcp/Ip Dataset = //DD:SYSTCPD > ==> PROD.APPLIB.PARM(TCPDATA) > Translation Table = PROD.STANDARD.TCPXLBIN > UserId/JobName = DVFJS > Caller API = LE C Sockets > Caller Mode = EBCDIC > (L) DataSetPrefix = PROD > (*) HostName = NODENAME > (*) TcpIpJobName = > (L) Search = fb > (L) SortList = 10.0.201.0/255.255.255.0 > (L) NameServer = 10.1.103.22 EDNS0 Support = Unknown > 10.29.100.5 EDNS0 Support = Unknown > (*) NsPortAddr = 53 (*) ResolverTimeout = 30 > (*) ResolveVia = UDP (*) ResolverUdpRetries = 1 > (*) Options NDots = 1 > (L) Trace Resolver (*) SockNoTestStor > (*) AlwaysWto = NO (*) MessageCase = MIXED > (L) LookUp = LOCAL DNS >res_init Succeeded >res_init Started: 2010/04/15 17:28:23.806552 >res_init Ended: 2010/04/15 17:28:23.806560 >********************************************************* ****************** >GetAddrInfo Started: 2010/04/15 17:28:24.057779 >GetAddrinfo Invoked with following inputs: > Host Name: opsserver23 > No Service operand specified > Hints parameter supplied with settings: > ai_family = 0, ai_flags = 0x00000072 > ai_protocol = 6, ai_socktype = 1 >GetAddrInfo Opening Socket for IOCTLs > BPX1SOC: RetVal = 0, RC = 0, Reason = 0x00000000 > BPX1IOC: RetVal = 0, RC = 0, Reason = 0x00000000 >GetAddrInfo Opened Socket 0x00000001 >GetAddrInfo Only IPv4 Interfaces Exist >GetAddrInfo Searching Local Tables for IPv4 Address > SITETABLE from dsprefix PROD.HOSTS.SITEINFO > - Lookup for opsserver23.fb > ADDRTABLE from dsprefix PROD.HOSTS.ADDRINFO > - Lookup for 10.0.11.9 >GetAddrInfo Returning Zero as Port Number >GetAddrInfo Built 1 Addrinfos >GetAddrInfo Closing IOCTL Socket 0x00000001 > BPX1CLO: RetVal = 0, RC = 0, Reason = 0x00000000 >GetAddrInfo Succeeded: IP Address(es) found: > IP Address(1) is 10.0.11.9 >GetAddrInfo Ended: 2010/04/15 17:28:24.205844 >-------------------------------------------------------------------- > >It proves that it found the local hosts IP address for opsserver23.fb (10.0.11.9) and not the real one (10.0.11.6). >On SYSPRINT I see: >EZY2640I Using 'PROD.ftp.DATA' for local site configuration parameters. >which shows that "DatasetPrefix PROD" allowed me to point to the PROD.FTP.DATA file. >And all is good! > >On a related note, I am curious what affect changing DATASETPREFIX in the system TCP.DATA file would do. Our site standard is to have SYS2.sysid as the HLQ for system config files. So we could have something like: >DATASETPREFIX SYS2.PRD1.TCPIP >or maybe just >DATASETPREFIX SYS2.PRD1 > >But that would mean that those files that are currently installed "as is" with the TCPIP hlq would need to be renamed or copied to have this other hlq. But I can't find an authoritative list of all of the dataset names that are resolved by the TCPIP DATASETPREFIX. > >The point is, even though we could specify GLOBALIPNODES ('SYS2.PRD1.PARMLIB(IPNODES)') in the Resolver setup file, I think the only way that we could point by default to an FTP.DATA file that pretty much follows our site standards (meaning that both TCPIP.FTP.DATA and SYS1.TCPPARMS(FTPDATA) are not allowed because they don't follow the site standard for such files) would be to create SYS2.PRD1.FTP.DATA and specify "DATASETPREFIX SYS2.PRD1". My question is, what other files that currently have the TCPIP HLQ would be affected? (We do have a TCPIP hlq, we just cannot have anything in it other than the IBM installed defaults). > >Kind of a rambling message. Hope some of this make at least a little sense! > >Frank > > > >-- > >Frank Swarbrick >Applications Architect - Mainframe Applications Development >FirstBank Data Corporation - Lakewood, CO USA >P: 303-235-1403 ---------------------------------------------------------------------- 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
