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
