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 Users 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 Users 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 Users 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 Users 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 Users 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 Users 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 Users 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 Users 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
