Rogers, In principle, you get about 2,200 folk on this list as opposed to only about 850 on the IBMTCP-L list, a potential increase of 1,350 (assuming the IBMTCP-L list is completely included in this list), but, that said, you'll probably pick up the same old names responding to this issue that you got on IBMTCP-L - maybe a few more who are too busy to bother with more than the list which mainly covers their interests.
In case you didn't see the response I sent you yesterday - well, it's yesterday here but I guess it's today for you even if it is the evening - I'll post it here too - with some additions. Oh - and I see somebody's already cracked a "Smith and Wesson" joke so I won't bother. <g> <copies> Newsgroups: bit.listserv.ibmtcp-l Date: Wed, 10 May 2006 15:49:03 +0200 ... From: Chris Mason <[EMAIL PROTECTED]> Subject: Re: Using TCPIP Hosts file Rogers, Sorry for the late response. I'm trying to catch up. How do we know that the batch FTP job is using a TCPIP.DATA file which allows the HOSTS.ADDRINFO and HOSTS.SITEINFO you set up to be found and accessed? What name were you using in place of the <hlq> Brian mentioned? By default it should be TCPIP. On the other hand, your HOSTS.LOCAL, HOSTS.ADDRINFO and HOSTS.SITEINFO may be "qualified" by your TSO userid. You need to make sure which of the files in the famous table in section 1.2.8.2, "Resolver configuration files", in the CS IP Configuration Guide will apply to your batch FTP job. Chris Mason ----- Original Message ----- From: "Laine, Rogers" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibmtcp-l ... Sent: Friday, 05 May, 2006 10:03 PM Subject: Re: [IBMTCP-L] Using TCPIP Hosts file > Brian, > > From your below information I was able to run the MAKESITE command and > it created the HOSTS.ADDRINFO & HOSTS.SITEINFO > > Also did the F RESOLVER,REFRESH and got the below messages... > > > F RESOLVER,REFRESH > EZZ9298I DEFAULTTCPIPDATA - None > EZZ9298I GLOBALTCPIPDATA - None > EZZ9298I DEFAULTIPNODES - None > EZZ9298I GLOBALIPNODES - None > EZZ9304I NOCOMMONSEARCH > EZZ9293I REFRESH COMMAND PROCESSED > > But when I run the batch FTP job replacing the IP address with a HOST > Name that I put in the HOSTS.LOCAL file it does not find this name. > > Do you know if I need to modify the TCPIP PROFILE? > > Rogers > -----Original Message----- > From: Brian D Phillips [mailto:[EMAIL PROTECTED] > Sent: Friday, May 05, 2006 2:21 PM > ... > Subject: Re: [IBMTCP-L] Using TCPIP Hosts file > > Rogers, > > The HOSTS file is one way to do it; the other is to point your IP stack > at an outboard Domain Name Server. (Well, you could also bring up a > z/OS > DNS, but that's not a quick and easy thing.) Anyhow, for the host > file > update to take effect: > > 1) EDIT <hlq>.HOSTS.LOCAL file, making changes as needed > > 2) TSO command MAKESITE HLQ=<hlq> (this creates / updates > <hlq>.HOSTS.ADDRINFO and <hlq>.HOSTS.SITEINFO using the "source code" > from step 1 as input) > > 3) CONSOLE command F RESOLVER,REFRESH > > Regards, > Brian P. </copies> The possible ways to "find" the "local host tables" are as follows: 1. X_SITE environment variable 2. X_ADDR environment variable 3. /etc/hosts 4. userid.HOSTS.xxxxINFO 5. jobname.HOSTS.xxxxINFO 6. hlq.HOSTS.xxxxINFO 7. GLOBALIPNODES 8. RESOLVER_IPNODES environment 9. userid.ETC.IPNODES 10. jobname.ETC.IPNODES 11. hlq.ETC.IPNODES 12. DEFAULTIPNODES 13. /etc/ipnodes Why such a ridiculously complicated list? I hear you ask. Well, you're right. It's history and the firm IBM commitment - well, almost firm - never to allow anything that worked in the last release not work in this release. And it's not that long a history either - something a little over 10 years. First there was TCP/IP for VM which did everything by allocating, typically - maybe exclusively - sequential data sets dynamically - because that's the way CMS is. Perhaps I should say before the beginning was an idea that an RFC which suggested that local name files should have the peculiar format you've been using for the source should be used instead of the more simple layout favoured by UNIX systems.Then TCP/IP for VM was "ported" to TCP/IP for MVS. This sort-of accounts for the 4, 5 and 6 options, one of which - and we've got to work out which one - you've been using . Then the Unix System Services stuff got added to z/OS and its ancestors, the "resolver" got to become a separate address space and the "local host table" got to use the UNIX-like format. I expect if I tried really hard I could come up with a justification for all the other options based on all these enhancements. Unfortunately I haven't been following TCP/IP for MVS - morphing into Communications Server IP - closely for most of the last 10 years so I can't say from where the inspiration for all of these accretions arose. Perhaps somebody still reading feel sufficiently inspired so to do. Checking the manual later, I discovered that another complicating influence is whether the IP address is V4 or might also be V6. As I said, we need to work out how to ensure your batch FTP job can "get at" your HOSTS.ADDRINFO and HOSTS.SITEINFO files. There are 3 options and 3 techniques. I'll suggest them in the order of greatest to least confidence. The first *must* work because it's what I used to do when I worked with the "local host table" file. 1. hlq.HOSTS.xxxxINFO (6 above) After I had created the HOSTS.ADDRINFO and HOSTS.SITEINFO files with the MAKESITE command, I renamed from MASON.HOSTS.ADDRINFO and MASON.HOSTS.SITEINFO to TCPIP.HOSTS.ADDRINFO and TCPIP.HOSTS.SITEINFO. TCPIP was my "hlq", in other words the value of my DATASETPREFIX statement from the TCPIP.DATA file. I *do* hope you have sorted out how your batch FTP job has access to a TCPIP.DATA file. If not, please post again and we'll try to sort that out[1]. Incidentally TCPIP is the default value if the DATASETPREFIX statement is not present. I see from Brian's post that you can actually specify the "hlq" on the MAKESITE command. That was either something not available when I used to use the MAKESITE command - or - I "missed a trick" - again. 2. jobname.HOSTS.xxxxINFO (5 above) If your "local host table" files are for use only with the batch FTP job, once you have decided on the jobname, you can rename the files to have the first token as the name of the job. Thus, if your job is FTPBATCH, the files could be named FTPBATCH.HOSTS.ADDRINFO and FTPBATCH.HOSTS.SITEINFO. I've never tried this but that's what the book implies works. 3. userid.HOSTS.xxxxINFO (4 above) If you'd like to reserve these "local host table" files only for your use, you might like to leave them with your userid as the first token. Thus, if your job is ROGERS, the files could be stay as ROGERS.HOSTS.ADDRINFO and ROGERS.HOSTS.SITEINFO. You then need to specify your userid using the USER operand of the JOB statement of the batch FTP job or submit the batch FTP job from your TSO logon. I may have tried this in one context or another but I can't remember whether I did or not. In any case again it's what the book implies works. I see you mention adjusting JCL. Unfortunately, because of the birth of mainframe TCP/IP in the VM world, dynamic allocation by data set name has always tended to be the favourite technique for data set allocation and would appear to be the exclusive technique with the "local hosts table" files. I thought I had finished here but I did some more checking. The list above is *not* a search order but just a list of techniques. The search order depends on what you are doing: what sort of program you are invoking in what environment - it gets worse, doesn't it? In section 1.2.8.2, "Resolver configuration files", of the CS IP Configuration Guide, we find that, in the case of FTP(batch), the "native MVS search order" is used. Cutting though all the verbiage in section 1.2.8.2.2, "Search orders used in the native MVS environment", and taking the default path - since I know you haven't coded anything in the resolver control statements, we discover that the 3 techniques I described above apply and apply in the reverse order, in other words, using my example first tokens: ROGERS, FTPBATCH, TCPIP. [1] If you feel more comfortable just using a JCL DD statement, you can ensure that your batch FTP job finds the desired TCPIP.DATA file using the //SYSTCPD DD statement. This may be all you need bother with for now. Reading on in the manual, I see that, for long-running "jobs" - that includes started tasks of course - you should use a partitioned data set in order to be able to use MODIFY RESOLVER to pick up changes. That's only ironic for someone who used TCP/IP for MVS in its early days when the only partitioned data sets in sight were the product libraries. Chris Mason ----- Original Message ----- From: "Laine, Rogers" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <IBM-MAIN@BAMA.UA.EDU> Sent: Wednesday, 10 May, 2006 10:54 PM Subject: Revolver Issue > I'm trying to setup a default revolver using Local Hosts file on MVS. > When using FTP under TSO it's able to find the Server name, but if I try > a batch job it does not locate the same Server name. > What do I need to code in the JCL to locate the correct Server using > Local Hosts? > > Rogers > > ________________________________________________________________ ---------------------------------------------------------------------- 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
