Well, it was __intended__ to go off-list.
Apologies to all, and especially to Chris.
-jc-
> -----Original Message-----
> From: Chase, John
> Sent: Thursday, April 15, 2010 8:07 AM
> To: 'IBM Mainframe Discussion List'
> Subject: RE: FTP to z/OS Problem
>
> Off-list:
>
> Context suggests you should have written "principal" instead of
"principle" in all cases noticed via a
> cursory perusal.
>
> -jc-
>
> > -----Original Message-----
> > From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf Of Chris Mason
> > Sent: Wednesday, April 14, 2010 9:17 PM
> > To: [email protected]
> > Subject: Re: FTP to z/OS Problem
> >
> > To those using the archives searching for information on SYSTCPD
> >
> > Also to Edward Jaffe, Charles Mills and Marty French if they happen
to notice
> > this thread to which they contributed is still running
> >
> > -
> >
> > This thread started - and largely appeared to finish - in
mid-December last
> > (2009). I thought it had been swiftly dispatched after a few
responses but a
> > tangent kicked in - and an expression regarding the sovereignty of a
territory
> > populated by the visually impaired came to mind!
> >
> > So I'm glad the thread has been resuscitated.
> >
> > Ideally this topic and the following extended discussion should have
taken
> > place in the IBMTCP-L list. It might then have not needed to be such
an
> > extended discussion!
> >
> > The tangent concerns the SYSTCPD DD-statement name and its
relevance.
> >
> > The point to establish is to explain the rather peculiar use of the
concepts
> > of "client" and "server" adopted by the original IBM product for
support for IP
> > communication and functions relating to IP, namely "TCP/IP for VM"
back in
> > the early '90s.
> >
> > There is the traditional concept of a "client" and a "server" where
a "client"
> > function, often a human end user at a workstation, requests services
of
> > a "server" function, a "whatever" since the traditional "client"
doesn't really
> > care.
> >
> > However, there is also a rather special "client" to "server" concept
originally
> > used by "TCP/IP for VM" and carried by inheritance through "TCP/IP
for MVS"
> > to the z/OS Communication Server (CS) IP component.
> >
> > This "client" to "server" concept is the relationship between z/OS
address
> > spaces. There is a principle CS IP address space, the one often
using the
> > name TCPIP, and there are a number of other address spaces which in
some
> > way are subordinate to this principle address space. The principle
address
> > space is the "server" address space and the subordinate address
spaces are
> > the "client" address spaces.
> >
> > Why do I postulate this structure? Well, let us examine the peculiar
token
> > name applied in the PORT statement list entry to the TN3270 "server"
function
> > in CS IP prior to the disengagement from the principle CS IP address
space.[1]
> > It was "INTCLIEN". What do you suppose that meant? Well, shall we
> > try "internal client"? But, wait just a moment, we are talking about
a "server"
> > function here are we not? Well, yes we are - in the traditional
"client-server"
> > structure. However, in the "client-server" structure of the CS IP
address
> > spaces, the TN3270 "server" function is a "client" and, prior to the
> > disengagement, was "internal" to the principle CS IP "server"
address space.
> >
> > Have you been keeping up at the back?
> >
> > I'm sorry I guess that's my teacher's style showing through!
> >
> > Talking of teaching, in order to emphasise this "client-server"
address space
> > structure I used to use the description "client data set" for what
started out
> > life in "TCP/IP for VM" as the TCPIP DATA file. I assume that this
file must
> > have been - and probably still is - required in all VM "machines"
which are
> > subordinate to the principle "TCP/IP for VM" machine called by
default or
> > possibly by design, TCPIP. In the "port" to MVS in "TCP/IP for MVS"
the TCPIP
> > DATA file became TCPIP.TCPIP.DATA for its default manifestation and
is
> > referenced in the manuals as the TCPIP.DATA file as a generic way of
referring
> > to it.
> >
> > I find the term "client data set" only in my teaching notes from the
mid-'90s so
> > I guess it was never official IBM terminology.
> >
> > There is a term mentioned in the CS IP Configuration Guide but
actually rarely
> > used and, where it is used, rather ambiguously.
> >
> > <quote>
> >
> > The ... program uses the following resolver directives (TCPIP.DATA
> > statements):
> >
> > </quote>
> >
> > The following is a sentence used to introduce the term in the CS IP
> > Configuration Guide and also in the UNIX System Services Planning
manual.
> >
> > <quote>
> >
> > How and if the resolver uses name servers is controlled by
TCPIP.DATA
> > statements (resolver directives).
> >
> > </quote>
> >
> > It may be that the term "resolver directives" is supposed to concern
only the
> > statements in the file which refer to accessing name servers.
> >
> > Since this is not clear, this file is a key file in the context of
the revised
> > resolver function and a name is needed which does not prejudice to
which of
> > its manifestations reference is being made, I shall continue to
refer to this file
> > as the "resolver directives".
> >
> > [1] The possibility to disengage the TN3270 "server" function
appeared in z/OS
> > CS V1R6 and was imposed from z/OS CS V1R9.
> >
> > -
> >
> > The revised resolver function appeared in z/OS V1R2.
> >
> > Prior to the introduction of the revised resolver function, the
search order for
> > the "resolver directives" file was as follows:
> >
> > Environment variable - RESOLVER_CONFIG (if z/UNIX environment)
> > /etc/resolv.conf (if z/UNIX environment)
> > //SYSTCPD DD statement
> > x.TCPIP.DATA (where x is userid for the z/UNIX environment and
> > userid/jobname/procname for the MVS environment)
> > SYS1.TCPPARMS(TCPDATA)
> > TCPIP.TCPIP.DATA
> >
> > Following the introduction of the revised resolver function, the
search order
> > for the "resolver directives" file is as follows:
> >
> > Resolver address space setup file - GLOBALTCPIPDATA
> >
> > plus the first of the following if statements are missing from
> > GLOBALTCPIPDATA except those from the list below
> >
> > Environment variable - RESOLVER_CONFIG (if z/UNIX environment)
> > /etc/resolv.conf (if z/UNIX environment)
> > //SYSTCPD DD statement
> > x.TCPIP.DATA (where x is userid for the z/UNIX environment and
> > userid/jobname/procname for the MVS environment)
> > SYS1.TCPPARMS(TCPDATA)
> > Resolver address space setup file - DEFAULTTCPIPDATA
> > TCPIP.TCPIP.DATA
> >
> > Statements which are specified only in GLOBALTCPIPDATA if
> > GLOBALTCPIPDATA is used
> >
> > DomainOrigin/Domain
> > NSInterAddr/NameServer
> > NSPortAddr
> > ResolverTimeOut
> > ResolverUDPRetries
> > ResolveVia
> > Search
> > SortList
> >
> > The above is taken from my notes created shortly after the revised
resolver
> > function was introduced. It may be there have been minor changes
since. If
> > there have been major changes, I hope someone will care to point
them out.
> >
> > -
> >
> > In addressing the individual posts, the first task is to thank Gary
Ciampa for
> > introducing me to a novel way of submitting jobs using FTP. It
corresponds to
> > the section "Steps for submitting a job and automatically receiving
output"
> > under "Interfacing with JES" in Chapter 4, "Transferring data using
the File
> > Transfer Protocol (FTP)" of the CS IP User's Guide and Commands
manual. It is
> > *not* the technique I used to have my students use in their hands-on
> > sessions but perhaps it has been introduced since I ran my classes.
> >
> > From Marty French:
> >
> > > If you FTP-ing from a mainframe/mainframe or LPAR/LPAR, here is
some JCL.
> >
> > The JCL provided is suitable for any use of the CS IP traditional
"client" "FTP in
> > batch". You are likely to have fewer formatting problems if the FTP
"server" is
> > also z/OS or z/VM. This topic is covered in Appendix A, "Specifying
data sets
> > and files" in the CS IP User's Guide and Commands manual.
> >
> > > The SYSTCPD DD is the same one you have in your TCPIP started task
JCL.
> >
> > In principle - see above - the "TCPIP started task JCL" should be
the *one*
> > place SYSTCPD in particular and the "resolver directives" file in
general is
> > never needed. However, I see SYSTCPD is included as a DD-statement
in the
> > sample CS IP main address space started task procedure JCL in the CS
IP
> > Configuration Reference. I wonder if it was used for the TN3270
"internal
> > client" prior to V1R9 and - an effect that has been mentioned in
this thread -
> > IBM authors/developers didn't realise that it no longer had a role!
Note that
> > the CS IP Configuration Guide does indicate that a SYSTCPD
DD-statement
> > might be needed by the separated TN3270 "server" procedure JCL.
> >
> > From Charles Mills:
> >
> > > You don't (in my experience) need the SYSTCPD DD statement.
> >
> > You may.
> >
> > > ... SYSTCPD DD statement. I don't know what it does. It's not
documented,
> > AFAIK.
> >
> > True it is not documented in the CS IP User's Guide and Commands
manual -
> > where you later indicate you would like to have found it - but it is
fully
> > documented in the CS IP Configuration Guide.
> >
> > From Marty French:
> >
> > > I thought the SYSTCPD DD statement allowed the FTP process to go
to
> > NSINTERADDR statement in the parms for IP address of the name server
> > (which we have) and then append the DOMAINORIGIN name specified in
the
> > parms.
> >
> > As indicated above, the SYSTCPD DD-statement is just one of the ways
to
> > find the "resolver directives".
> >
> > > Since I'm new here what is 'AFAIK'.
> >
> > Google is your friend. You just have to Google AFAIK. QED.
> >
> > > ... SYSTCPD DD statement. I don't know what it does. It's not
documented,
> > AFAIK.
> >
> > Come to think of it, Charles Mills could have Googled SYSTCPD and
discovered
> > with the first hit that it most certainly is documented!
> >
> > From Charles Mills:
> >
> > > I happen to have the OS/390 2.10 and z/OS 1.2 FTP docs closest at
hand
> > and I get no hits in FTP for SVCFTPD
> >
> > You get one hit for SYSTCPD in the V1R11 edition of the CS IP User's
Guide
> > and Commands manual. It is not a very helpful one since it is found
in Chapter
> > 11, "Executing commands on a remote host".
> >
> > > I am 99% sure I have had name-type addresses resolve correctly
without it,
> > but I must admit that currently I mostly use dotted addresses.
> >
> > > You could be 100% sure since, as indicated above, the SYSTCPD DD-
> > statement is just one of the ways to find the "resolver directives".
> >
> > > Perhaps it was a former requirement.
> >
> > Being able to locate a "resolver directives" file always was, is and
always will
> > be a requirement for the "client" address spaces.
> >
> > > JCL statements that once helped tend to never get removed.
> >
> > Unless the file to which a JCL DD-statement refers is known to be
"history"
> > and is deleted - as might well have happened to the file referenced
by the
> > SYSTCPD DD-statement when your CS IP administrator implemented the
> > revised resolver function following z/OS V1R2.
> >
> > From Marty French:
> >
> > > We also run a TCP/IP print product called VPS TCP/IP from LRS
software.
> > We had to add the SVCFTPD DD statement to the started task to
resolve
> > printer addresses per their instructions, so I just assumed that
this was the
> > case with FTP JCL.
> >
> > I assume you mean SYSTCPD rather than SVCFTPD!
> >
> > What this means is that you should *understand* what you are doing.
> > Whether or not you actually *needed* SYSTCPD depends on how your CS
IP
> > administrator has set up the resolver function in your installation.
> >
> > CWCID: assuming that what applies to one CS IP "client address
space"
> > might/does apply to another CS IP "client address space" betrays
nous.
> >
> > From Edward Jaffe
> >
> > > SYSTCPD is needed only for special overrides, to use a specific
(non-
> > default) stack in a multi-stack configuration, or when -- probably
because of
> > a sysprog that doesn't know any better -- the installation has not
made the
> > proper TCPDATA file available via the normal search sequence. I
never use
> > SYSTCPD. Things are set up here so it is not needed. However, any
JCL we
> > distribute to customers that uses FTP contains the following
commented JCL
> > statements:
> >
> > > //*SYSTCPD DD DISP=SHR,DSN=... <- only needed for non-standard
> > > //*SYSFTPD DD DISP=SHR,DSN=... <- configurations.
> >
> > It is unclear to me how the DEFAULT parameter - which is I assume
what you
> > mean by "default" here - on the SUBFILESYSTYPE TYPE(CINET) statement
> > interacts with the TCPIPJOBNAME statement in the "resolver
directives" file. It
> > doesn't help that the UNIX System Services Planning manual, when
given the
> > chance in Chapter 19, "Setting up for sockets", "Resolver
configuration
> > files", "Resolver information" - yet another name for the TCPIP.DATA
file,
> > doesn't bother to provide any clarification either. Thus I would
advise that for
> > any "client address space" needing to select one of a number of CS
IP
> > instances, the appropriate TCPIPJOBNAME - by whatever means suits
best -
> > should be specified. That probably would be by means of a SYSTCPD
DD-
> > statement.
> >
> > There is also a discussion in the z/OS CS IP Configuration Guide in
Chapter
> > 2, "IP configuration overview", "Considerations for multiple
instances of
> > TCP/IP", "Selecting a stack when running multiple instances of
TCP/IP".
> >
> > I can't be sure but I suspect you have not re-evaluated your
philosophy
> > regarding the "resolver directives" file since z/OS V1R2 when the
resolver
> > function was redesigned.
> >
> > Your comment is far too narrow. It should be something on the lines
> > of "according to your installation's design for the resolver
function".
> >
> > From Charles Mills:
> >
> > > Sure would be nice if IBM documented it, then.
> >
> > This is a valid point. There should be an indication in the CS IP
User's Guide
> > and Commands manual - which is designed for "users" after all -
wherever JCL
> > is offered for a "client" function that attention should be paid to
the "resolver
> > directives" file in terms of referring to the local installation's
policy regarding
> > the resolver function. This policy may well involve specification of
SYSTCPD -
> > or it may not.
> >
> > > There should be an explicit explanation of SYSTCPD in the FTP
client
> > documentation if it is relevant to FTP, with perhaps a reference to
the
> > Configuration manual if more detail is wanted.
> >
> > No. In the interests of having only one version of the documentation
regarding
> > the "resolver directives" file, it should be mentioned that the
"user" should
> > consult the appropriate authority in the installation in order to
discover how
> > the matter of the "resolver directives" file is resolved. As I
explained above
> > the "resolver directives" file applies also to address spaces other
than "client"
> > address spaces as "client" is usually understood. Thus it would be
> > inappropriate to described the "resolver directives" file
exclusively in the CS IP
> > User's Guide and Commands manual. It belongs where it is in the CS
IP
> > Configuration manuals.
> >
> > Also, as you can tell from above, in general you always need all the
detail but,
> > for any one installation where the matter of the "resolver
directives" file has
> > been sorted out already, the "user" just needs the local
information.
> >
> > Incidentally, the "Joe Programmer" who asks for help in a list like
this and gets
> > bunged some JCL must expect that what is provided may depend on the
way
> > that installation works and may not be fully appropriate to the way
his or her
> > installation works. That's just logical - if you stop to think a
moment!
> >
> > > Especially since the BookManager search facility seems to be
flawed: I get
> > no hits for SYSTCPD when I search the IP bookshelf - although it's
there as
> > big as life (as you say) in the Configuration manual.
> >
> > It works brilliantly for me! Of course, there is no "IP" bookshelf
but there is
> > a "Communications Server" bookshelf, the one I tried.
> >
> > > IMHO one of the big problems facing the mainframe going forward is
> > documentation which cannot be used effectively unless you ALREADY
know all
> > about whatever you are looking up.
> >
> > I'm inclined to agree. It helps enormously to have "grown up" with
the OS
> > (PCP, MFT, MVT) ... z/OS library so that you noted the manual -
particularly
> > title - changes as they happened over the past 40 + years. I believe
you are
> > supposed to get the necessary orientation to any IBM technical
territory by
> > having attended the relevant education classes. If you haven't
attended the
> > classes relevant to the tasks you are asked to perform I guess that
is
> > your "suits" trying to avoid expense they regard falsely as
unnecessary.
> >
> > From Edward Jaffe:
> >
> > > SYSTCPD is not used by FTP, ...
> >
> > It is - as indicated above.
> >
> > > ... but its presence or absence in the JCL can make a tremendous
difference
> > in the outcome of the job. It defines site-wide, stack-wide,
resolver-wide,
> > settings that affect all TCP/IP clients and servers.
> >
> > Hm, we're talking about an individual "client" address space
corresponding to a
> > job performing the "client" role in the traditional "client-server"
setup. I don't
> > see that making any difference to any address space except the one
where it
> > is specified - and I further don't see it having much of a
performance impact -
> > except perhaps with unusual configurations with many unresponsive
name
> > servers ...
> >
> > What you describe could be used to refer to the data set identified
by the
> > GLOBALTCPIPDATA - if fully populated - baring the TRACE statements
of
> > course - or the DEFAULTTCPIPDATA statements in the RESOLVER
procedure
> > setup file or, indeed, the old TCPIP.TCPIP.DATA file as copied from
the TCP/IP
> > for VM ancestor.
> >
> > > I would not expect to find a discussion of SYSTCPD repeated for
each and
> > every client or server supported by TCP/IP. That would be analogous
to
> > explaining JOBLIB/STEPLIB in the documentation for every mainframe
> > application ever written.
> >
> > Your reasoning is good, of course, this is Edward Jaffe territory,
but be
> > assured, all "client address spaces" need to refer to the "resolver
directives"
> > file - for example to convert "TCP" in the socket() call to protocol
number 6. A
> > batch FTP "client" job as described under "Submitting FTP requests
in batch"
> > in Chapter 4, "Transferring data using the File Transfer Protocol
(FTP)" in the
> > CS IP User's Guide and Commands manual is one such "client address
space".
> >
> > > Most sites would never use SYSTCPD for the default stack.
> >
> > There are a number of reasons for having individual subsets of
"resolver
> > directive" parameters. One that immediately springs to mind -
actually it didn't
> > but it should have! - is a way to set on the trace function - TRACE
RESOLVER
> > or TRACE SOCKET - for the "client address space".
> >
> > Your emphasis on the "default" CS IP instance is distorted.
> >
> > > It is a throw-back to very, very old IBM TCP/IP stacks and -- even
then --
> > its use was discouraged.
> >
> > Not really. When SYSTCPD was introduced, it was a relief for users
as a way
> > of avoiding having to create data sets allocated by having to have a
userid as
> > the first token. Again you have a very distorted view.
> >
> > I invite you to scan the CS IP Configuration Guide and Reference
manuals in
> > order to see whether or not the use of the SYSTCPD DD-statement is
> > discouraged.
> >
> > Following the redesign of the resolver function, there should be a
move within
> > the installation to try to remove the need for SYSTCPD - and all
those other
> > ways of specifying the "resolver directives" file. To that extent
SYSTCPD is
> > a "throw-back" but this is only since z/OS V1R2, 2003. I guess some
might
> > describe 2003 as very, very old!
> >
> > > For those shops that use it (whatever their reason), ...
> >
> > And there are a number of such reasons.
> >
> > > ... it is their responsibility to communicate their SYSTCPD DD
requirements
> > to their user community.
> >
> > I think we may finally have some sort of agreement! It is necessary
to consult
> > your CS IP administration in order to know the resolver policy -
perhaps it's
> > part of the installation's specific documentation maintained by the
CS IP
> > administrator or the consultants who provide the CS IP
administration service.
> >
> > From Charles Mills:
> >
> > > I would counter that since there is only ONE manual (that comes to
mind
> > anyway) that documents ALL of the IP "utilities" (or commands as IBM
calls
> > them) that it would not hurt if a search on SYSTCPD in that book at
least
> > produced at least a reference to the appropriate manual. And I have
> > communicated that thought to IBM.
> >
> > No. You are wrong. It could be argued that the reason you are wrong
is that
> > you have confused "client" as it applies to the "client-server"
relationship
> > between address spaces with the "client" as it applies traditionally
to
> > the "client-server" relationship and describes the users of the CS
IP User's
> > Guide and Commands manual. For that you are excused - although I'm
not
> > quite sure your confusion relates to an understanding approaching
that level
> > of advancement!
> >
> > -
> >
> > Chris Mason
> >
> > On Tue, 13 Apr 2010 09:04:15 -0400, Shmuel Metz (Seymour J.)
<shmuel+ibm-
> > [email protected]> wrote:
> >
> > >In <00bc01c4e179$2373a390$67fea...@charlesnotebook>, on 12/13/2004
> > > at 05:06 PM, Charles Mills <[email protected]> said:
> > >
> > >>IMHO one of the big problems facing the mainframe going forward is
> > >>documentation which cannot be used effectively unless you ALREADY
know
> > >>all about whatever you are looking up.
> > >
> > >As opposed to the windows world where there often is no
documentation.
> > >
> > >>How would anyone
> > >>answer the question "how do I do disk I/O from an assembly
program"
> > >
> > >By asking for the relevant data, e.g., for what platform.
> > >
> > >>unless one already knew that the information would be found in
"DFSMS
> > >>Macro Instructions for Datasets"?
> > >
> > >Only for systems related to z/OS, and even then it might not be the
right
> > >answer. Just like on the PC; you need to ask the right question.
> > >
> > >--
> > > Shmuel (Seymour J.) Metz, SysProg and JOAT
> > > ISO position; see
<http://patriot.net/~shmuel/resume/brief.html>
> > >We don't care. We don't have to care, we're Congress.
> > >(S877: The Shut up and Eat Your spam act of 2003)
> >
> >
----------------------------------------------------------------------
> > 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
----------------------------------------------------------------------
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
