Frank > "EZY2640I Using 'PROD.FTP.DATA' for local site configuration parameters."
The search order for the file FTP DATA is given in Table 3, "TCP/IP configuration data sets" in a section of the same name under "Configuration data set naming conventions" under "Understanding search orders of configuration information" in Chapter 2, "IP configuration overview" of the z/OS Communications Server IP Configuration Guide as follows: <quote> Name (search order) FTP.DATA 1. -f command line parameter (FTP client only) 2. The MVS data set or z/OS UNIX file specified on the SYSFTPD DD statement in the FTP server started procedure 3. userid/jobname.FTP.DATA 4. /etc/ftp.data 5. SYS1.TCPPARMS(FTPDATA) 6. hlq.FTP.DATA Copied from SEZAINST(FTCDATA) for the client and (FTPSDATA) for the server Usage Overrides default FTP client and server parameters for the FTP server. For more information about the hlq, jobname, or userid values, see Chapter 11, “Transferring files using FTP,” on page 661. </quote> I have had to disentangle the table format to some extent. I also suspect that the "(FTPSDATA) for the server" should be "SEZAINST (FTPSDATA) for the server". You need to acquaint yourself with the whole "Understanding search orders of configuration information" and some following sections in Chapter 2, "IP configuration overview", if not the whole of the chapter. I suspect that nearly all of your questions are answered there. > Well, barely customised. The "resolver" is considered customised if you change the SYS1.PARMLIB BPXPRMxx RESOLVER_PROC statement from RESOLVER_PROC(DEFAULT) to RESOLVER_PROC(something) where "something" is typically RESOLVER. You will then necessarily create a RESOLVER procedure and typically add a SETUP DD- statement which needs to refer to something. Having gone to this much trouble, it is then usual to consider how one might benefit from all this toil and sweat! > ... and the IBM defaults are assumed to be right until they are proven wrong; right? This is such an interesting topic I have created a separate thread in order to attract comments from at least the usual suspects. >> 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. > That last bit is certainly of interest. The what does this mean: > <quote> > PROFILE.TCPIP search order > The search order for accessing PROFILE.TCPIP information is as follows. The first file found in the search order is used. > 1. //PROFILE DD statement > 2. job_name.node_name.TCPIP > 3. hlq.node_name.TCPIP > 4. job_name.PROFILE.TCPIP > 5. hlq.PROFILE.TCPIP > </quote> > In this case where does HLQ come from? I thought this was a "good question" and it sort-of is. Our dear friends the manual authors have made a mess yet again. Having spent quite a while checking this out, I now think we have a failure fully to update the manuals when it was decided to "hardcode" that last step in the search order. Note that, if you have decided on using the PROFILE DD-statement all of this complicated discussion regarding "hlq" and "node-name" is moot and is, frankly, best left buried in the detritus of past and gratefully long-forgotten manifestations of "TCP/IP for MVS"/"the z/OS Communications Server IP component". The PROFILE data set search order is defined twice in the Configurations Guide and twice in the Configuration Reference. Although not at all democratic, since it is a minority of three to one, I believe the most correct version of the four is the following taken from "PROFILE.TCPIP search order" in "Configuration files for the TCP/IP stack", just after the famous Table 3 which contains the version you quoted in fact, in Chapter 2, "IP configuration overview" in the Configuration Guide: <quote> - //PROFILE DD DSN=aaa.bbb.ccc(anyname) - jobname.nodename.TCPIP - hlq.nodename.TCPIP - jobname.PROFILE.TCPIP - TCPIP.PROFILE.TCPIP </quote> The version you quoted can be found in the famous Table 3 in the Configuration Guide and twice in the Configuration Reference. I suspect, as usual, that the manual authors just forgot - a change of "shift" with no collective memory - that there was more than one version of this "search order" provided in the manual. In the beginning - or as far back as I can vaguely remember - TCP/IP for MVS was "hardcoded" with an "hlq" of TCPIP. There was an SMP USERMOD-style job that could be run in order to change this. The circumstances of my teaching systems was that they were copies of a production system that was post-SMP and so I could not run this SMP job. Instead I set up a massive SUPERZAP job which changed the upper teens number of instances where I was able to identify "TCPIP" in the load modules - just to show that the "hlq" could be changed. Then along came DATASETPREFIX and the "hlq" problem was largely solved. Probably at about the same time to the very many dynamically allocated data sets was added the option to use an MVS-style DD-statement rather than a dynamic allocation in a pale copy of the usual VM-style allocation of data sets. I was so enthusiastic about DD-statements - as I believe the "TCP/IP for MVS" developers were - that I largely forgot about the nightmares of dynamic allocation. There were only a few remaining instances of which HOSTS.LOCAL etc. was the worst. Checking with my notes - from 1995 - I dismiss the PROFILE data set allocation as follows: <quote> The TCP/IP main procedure allocates the profile parameters by means of the DD-statement PROFILE. Previously this was a data set allocated dynamically with the typical name TCPIP.PROFILE.TCPIP. Many and complex variations on this were possible. </quote> Having checked my notes, you may as well see what I was teaching about this topic 15 years ago: <quote> Data Set Allocation ------------------- -> Recommended from TCP/IP V3 - Main Procedure Profile Parameters -- allocate with DD-statement, PROFILE previously, typically, TCPIP.PROFILE.TCPIP - Main and Client Procedure Common Parameters -- allocate with DD-statement, SYSTCPD previously, typically, TCPIP.TCPIP.DATA -> identifies highest level qualifier, hlq, for data sets allocated dynamically - Client Procedure Parameters -- allocate with DD-statement, e.g. SYSFTPD for FTP server procedure previously, e.g. TCPIP.FTP.DATA - Data Sets Allocated Dynamically -- translation tables -- socket programming "look-up" tables -- local customized name resolution tables -- SNMP --- MIB data set - manager --- agent customized data sets </quote> Of the 'socket programming "look-up" tables', that is, PROTOcol and SERVICES, SERVICES can now be allocated with a DD-statement. So getting back to the PROFILE data set search order, for whatever reason the "hlq" for the last option has reverted to "hardcoded" TCPIP at some time - before z/OS V1R1, as far back as I can easily go. However I'm not at all sure about the third one. Is that really "hlq" and, if so, is it obtained from the DATASETPREFIX parameter of the TCPIP.DATA data set somehow associated with the Communications Server IP main address space? Incidentally note how curious and disingenuous the following actually is: <quote> 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> True the PROFILE data set used at one time in its tortured life to use the "hlq" as the highest level qualifier "in the last step of the search order". But, but, but - as you just told me, mate - the DATASETPREFIX statement provides the "hlq" and the DATASETPREFIX statement comes from the TCPIP.DATA data set - so, tell me, which comes first, the chicken or the egg ... In other words, forcing "TCPIP" as the last step in the search order for the PROFILE data set was optional but forcing "TCPIP" as the last step in the search order for the TCPIP.DATA data set was unavoidable in the sense that it certainly couldn't be "hlq"! > For that matter, where does NODE_NAME come from? nodename or node_name is also a bit complicated although relatively clear. It's not obligatory to use VMCF/TNF in the z/OS Communications Server IP component these days - as it used to be for "TCP/IP for MVS" - and so it's not obligatory to provide a nodename/node_name value. Thus those entries in the PROFILE name search which reply on nodename/node_name cannot apply. On the other hand, it seems you've implemented everything anyhow so I guess you have implemented VMCF/TNF. If so you should, for maximum flexibility, have set up the "replaceable" flavour. See "Step 3: Configure VMCF and TNF" in "Required steps before starting TCP/IP" in Chapter 2, "IP configuration overview" in the z/OS Communications Server IP Configuration Guide. As far as I can tell from the snippets of documentation, you need VMCF/TNF in order to run the SMTP and LPD servers and the TSO TELNET, HOMETEST, TESTSITE, and LPR commands. It's interesting that you do *not* seem to need VMCF/TNF for the MAKESITE command but you do still need VMCF/TNF in order to run the TESTSITE and HOMETEST commands. Note that there is a replacement for the SMTP server called CSSMTP in V1R11. However it is not a "one-for-one" replacement so, if you use SMTP, you may find that you need features of SMTP which are not present in CSSMTP. So, if you have implemented VMCF/TNF, you will know whence comes nodename. > I wonder if this answers my question above as to where HLQ comes from for TCPIP.PROFILE; hlq is perhaps the userID of the job...? Be aware that, wherever "jobname" is mentioned, you should use the explanation to be found under "jobname" in the description of the PORT statement in the Communications Server IP Configuration Reference manual[1]: <quote> The following list explains how to determine the jobname value given the environment in which the application is run: - Applications run from batch use the batch job name. - Applications started from the MVS operator console use the started procedure name as the job name. - Applications run from a TSO user ID use the TSO user ID as the job name. - Applications run from the z/OS shell normally have a job name that is the logged on user ID plus a one-character suffix. - Authorized users can run applications from the z/OS shell and use the _BPX_JOBNAME environment variable to set the job name. In this case, the value specified for the environment variable is the job name. - Use the name of the started JCL procedure for the UNIX System Services kernel address space to enable applications (except for applications using the Pascal API) to bind to the port. This name is typically OMVS unless a different name is explicitly specified in the STARTUP_PROC parameter of the BPXPRMxx parmlib member. - z/OS UNIX applications started by INETD use the jobname of the INETD server. - Use the name of the VTAM started task for the UDP ports that are to be used for Enterprise Extender (EE) network connections. </quote> It may be useful to keep this explanation handy for whenever "jobname" is mentioned but it's not easy to see what "job" might be intended - especially what there is no "job" in sight! >> 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): ... > Thanks. Interesting that FTP.DATA is not there, and yet it is affected by the DATASETPREFIX value... FTP.DATA is *not* there because it *can* be specified with a DD statements in JCL, namely SYSFTPD. See my extract above. > Other than this temporary testing issue we have, what is the usual use of a local "host lookup" file? Whatever use you discover you may need in the future. Possibly after some incremental migration of an application between initial testing, assurance and then finally when cutting over to production with the name server known to have the corresponding entry, the local name can be removed. Any time that you need to avoid the treacle-wading of getting the name server administrator to stir his/her stumps. > I don't know of any RPC use. What is something common on z/OS that might use this? Network File System (NFS). Any typically "server" product you use should say prominently whether or not it relies on RPC as some sort of "enabling" layer. > Same question as above. In effect > I don't know of any PROTO use. What is something common on z/OS that might use this? Each and every one of your programs using the socket interface (maybe including the programs using the Pascal interface and, if so, that would mean each and every program using APIs to the Communications Server IP component) potentially - and, if well-written, definitely - needs access to the data set generically named ETC.PROTO. I guess you missed the 'vital for the task of converting the characters "tcp" to 6 and the characters "udp" to 17' in my previous post! The full range of facilities included under the title "resolver" is as follows: - name to address and address to name translation, the resolver subject on which we have been concentrating so far - the translation of service names to service numbers supported by the generically named ETC.SERVICES data set - the translation of protocol names to protocol numbers supported by the generically named ETC.PROTO data set There is a subset of socket calls which rely upon these facilities. Well-written programs never rely on the numbers but always set up the text strings and use the socket calls in order to find out what the number is today. That way you can - should you ever need to - play games with the mapping of the text strings, such as "tcp" and "udp" in the example I used before and map the text strings to other numbers - for whatever reason. Before you ask, I doubt you ever will - but, in case of some catastrophe where IBM is offering all sorts of help with some bug or other, a temporary solution just might involve some fiddling with the generic ETC.SERVICES or ETC.PROTO data set and all will be grateful that the programmer didn't just hardcode the number. For some reason or other, the SERVICES lookup data set *can* use a DD- statement but, for some other reason or other, the PROTOcol lookup data set can't. I think the usual expression at a time like this is "Go figure!". Chris Mason [1] There may be other places with a full explanation but I haven't noticed them. On Sat, 17 Apr 2010 22:01:14 -0600, Frank Swarbrick <[email protected]> wrote: >Thanks for your responses. See imbedded comments. >-- > >Frank Swarbrick >Applications Architect - Mainframe Applications Development >FirstBank Data Corporation - Lakewood, CO USA >P: 303-235-1403 > > >On 4/15/2010 at 9:35 PM, in message ><listserv%[email protected]>, Chris Mason ><[email protected]> wrote: >> 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. > >Yeah, I do realize that. I mentioned it because it is one of those datasets that is affected by the DATASETPREFIX statement. >"EZY2640I Using 'PROD.FTP.DATA' for local site configuration parameters." > > > 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! > >Well, barely customised. The only difference between what we use and the version in 'TCPIP.SEZAINST(EZBREPRC)' is the SETUP DD: >//SETUP DD DSN=SYS2.PRD1.PARMLIB(RESSETUP),DISP=SHR,FREE=CLOSE >And that was done only to mean the site standard of using a SYS2.&SYSNAME.PARMLIB member. > >> 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. > >Hmm, I didn't think of dropping DNS altogether. Sounds like a good idea. > >> 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. > >Not sure either. Maybe to point out that using the SYSTCPD DD totally overrode anything in the DEFAULTTCPIPDATA dataset. Had the system been set up with a GLOBALTCPIPDATA dataset containing everything that is currently in the DEFAULTTCPIPDATA dataset my SYSTCPD dataset would only have needed: >Trace resolver >DatasetPrefix PROD >Lookup local dns >(I didn't really need SortList, though it probably should be in the global >one.) > >>> 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. > >Haha, I doubt I'd be stopped. It was simply installed using the IBM defaults, and the IBM defaults are assumed to be right until they are proven wrong; right? > >>> 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. > >That last bit is certainly of interest. The what does this mean: ><quote> >PROFILE.TCPIP search order > >The search order for accessing PROFILE.TCPIP information is as follows. The first file found in the search order is used. > > 1. //PROFILE DD statement > 2. job_name.node_name.TCPIP > 3. hlq.node_name.TCPIP > 4. job_name.PROFILE.TCPIP > 5. hlq.PROFILE.TCPIP > </quote> > >In this case where does HLQ come from? For that matter, where does NODE_NAME come from? > >> </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> > >Thanks. Interesting that FTP.DATA is not there, and yet it is affected by the DATASETPREFIX value... >I wonder if this answers my question above as to where HLQ comes from for TCPIP.PROFILE; hlq is perhaps the userID of the job...? > >>> 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. > >Nah, I have enough trouble with English. :-) > >Seriously, though, I keep worrying that we will run in to an issue with the fact that the default TCPXLBIN uses EBCDIC Code Page 1047 (Open Systems) instead of 037 (or 1140). Our Cobol programs use 037. BUt until we actually have files that have brackets or carets etc. in it I don't see that there will be an appetite for changing from the IBM supplied default. > >> 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. > >Indeed. Don't know if that day will come. Other than this temporary testing issue we have, what is the usual use of a local "host lookup" file? > >> If you use "Remote Procedure Call" (RPC) I guess you're stuck with ETC.RPC. > >I don't know of any RPC use. What is something common on z/OS that might use this? > >> 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] > >Same question as above. > >> Chris Mason > >Thanks again, Chris! > >Frank ---------------------------------------------------------------------- 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
