Permit multiple TCPIP configuration libraries at startup

Alternative approaches exist to accomplish this (mentioned in earlier comments)

Thanks for the clarification. As we discussed there's currently no mechanism to do this in the same exact manner as is done in VTAM configuration. This is partially because of the flexibility in TCP/IP to specify configuration in sequential or PDS data sets with any naming convention the admin selects. Here's a method you may want to consider that will work with today's support. Define a JCL symbol that helps resolve the PROFILE dataset name when the START command is issued. For example:

000001 //TCPCS3 PROC PARMS='CTRACE(CTIEZBN0)',
000002 // P=PROF1
000003 //TCPCS3 EXEC PGM=EZBTCPIP,REGION=0K,TIME=1440,PARM='&PARMS'
000004 //PROFILE DD DISP=SHR,DSN=USER1.TEST.TCPPARMS(&P)
000005 //SYSTCPD DD DISP=SHR,DSN=SYS1.TCPPARMS(TCPDATA)

Normal operations, you issue S TCPCS3 and the profile used in USER1.TEST.TCPPARMS(PROF1)
When you want to start TCP/IP with an alternate profile for testing purposes you could copy PROF1 into PROF2 and make the relevant changes. Then start TCP/IP using:

S TCPCS3,P=PROF2

That would direct TCP/IP to use USER1.TEST.TCPPARMS(PROF2) for test purposes. Once testing complete, propagate changes back to PROF1 and restart using normal Start command.

Obviously, a different approach with some of its own pros/cons. Just wanted to mention this possible option for consideration.

I am not sure I made it clear what I am asking to do.

Currently I have this concatenation in my NET PROC:
//VTAMLST DD DSN=SYS1.MVSB.VTAMLST.ALT,DISP=SHR
// DD DSN=SYS1.MVSB.VTAMLST,DISP=SHR

So if I want to try a new ATCCON00 or ATCSTR00, I put it in SYS1.MVSB.VTAMLST.ALT. If there is no member there than it finds the member in SYS1.MVSB.VTAMLST.

I would like to do something similar for the TCPIP PROFILE (and other configuration data sets to the extent possible), so I would code something like:
//PROFILE DD DSN=SYS1.MVSB.TCPPARMS.ALT(PROFILE),DISP=SHR
//PROFILE DD DSN=SYS1.MVSB.TCPPARMS(PROFILE),DISP=SHR

If a member is found in SYS1.MVSB.TCPPARMS.ALT, the search ends. Otherwise it falls through.

If you can explain something that approximates this, that would be great.

Our apologies for the very delayed response, had not gotten notification on the update you had made. If you use the PROFILE DD method the statements will be processed in the exact order of the specified data sets from top to bottom. When using the INCLUDE statement, the statements in that data set will get pulled in exactly where the INCLUDE statement appears in the profile. So the order is predictable in both cases. Note however, that if you have duplicate definitions between the various data sets the rules of what occurs varies depending on the statement type. For some statements, the last occurrence of the statement wins (i.e. overrides earlier settings). For others, subsequent instances of the same statement may be ignored or result on an error message. Does that explanation help?

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - z Systems Software
Product - z/OS Communications Server

For recording keeping, the previous attributes were:
Brand - WebSphere
Product family - Enterprise Networking
Product - z/OS Communications Server

If I understand this correctly, I could have a parts of my PROFILE in two different members. Would all of the parameters in both members be used to initialize TCP? Which would have precedence?

It seems like you are saying I could have a generic INCLUDE coded in the PROFILE. If I set a parameter in the PROFILE and the have the opposite setting in the INCLUDE, which has precedence?

There are several methods that can be used to accomplish this today.
1) You can concatenate multiple PDS datasets on the Profile DD card but the members need to be specified explicitly. For example:
//PROFILE DD DISP=SHR,DSN=USER1.TEST.TCPPARMS(CUSTOM)
// DD DISP=SHR,DSN=USER1.TEST.TCPPARMS(BASE)

2) You can alsouse the INCLUDE statement in the TCP/IP profile to import any additional configuration into your profile. The INCLUDE statement can point to any other data set that may contain additional TCP/IP profile definitions. This data set can be empty andonly used when you have a need to override some TCP/IP profile definitions.

I think these 2 methods should provide you a means to do what you would like. Do you agree?

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - WebSphere
Product family - Enterprise Networking
Product - z/OS Communications Server
Component - TCP/IP
Operating system - IBM z/OS
Source - None

For recording keeping, the previous attributes were:
Brand - Servers and Systems Software
Product family - zSeries Software
Product - z/OS
Component - Service
Operating system - IBM z/OS
Source - None

Creating a new RFE based on Community RFE #69234 in product z/OS.