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
The information contained in this electronic communication and any document
attached hereto or transmitted herewith is confidential and intended for the
exclusive use of the individual or entity named above. If the reader of this
message is not the intended recipient or the employee or agent responsible for
delivering it to the intended recipient, you are hereby notified that any
examination, use, dissemination, distribution or copying of this communication
or any part thereof is strictly prohibited. If you have received this
communication in error, please immediately notify the sender by reply e-mail
and destroy this communication. Thank you.
----------------------------------------------------------------------
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
