Re: Changing TCPIP PROFILE EXEC
Alan: I have moved the COMMAND statements to the top before the INCLUDE TCPCMSU which has DEV type statements like SPOOL, CONSOLE, LINK and it IPLs CMS. Hopefully this is correct now. USER TCPIP TCPIP 128M 256M ABG COMMAND ATTACH 9400 TO * 9000 COMMAND ATTACH 9401 TO * 9001 COMMAND ATTACH 9402 TO * 9002 COMMAND ATTACH 9000 TO * 9000 COMMAND ATTACH 9001 TO * 9001 COMMAND ATTACH 9002 TO * 9002 INCLUDE TCPCMSU OPTION QUICKDSP SVMSTAT MAXCONN 1024 DIAG98 APPLMON SHARE RELATIVE 3000 IUCV ALLOW IUCV ANY PRIORITY IUCV *CCS PRIORITY MSGLIMIT 255 IUCV *VSWITCH MSGLIMIT 65535 * CHANGE SPECIAL FROM 9104 TO 9108 PER SAM 9/30/09 SPECIAL 9108 QDIO 3 SYSTEM OSALAN LINK 5VMTCP40 491 491 RR LINK 5VMTCP40 492 492 RR LINK TCPMAINT 591 591 RR LINK TCPMAINT 592 592 RR LINK TCPMAINT 198 198 RR MDISK 191 3390 2258 005 540W02 MR RTCPIP WTCPIP MTCPIP PROFILE TCPCMSU IPL CMS MACH ESA SPOOL 000C 2540 READER * SPOOL 000D 2540 PUNCH A SPOOL 000E 1403 A CONSOLE 009 3215 T LINK MAINTSYS 0190 0190 RR LINK MAINTSYS 019D 019D RR LINK MAINTSYS 019E 019E RR LINK MAINTSYS 0402 0402 RR LINK MAINTSYS 0401 0401 RR LINK MAINTSYS 0405 0405 RR The mprout was indeed a cut and paste error. But the SYSTEM DTCPARMS is on TCPMAINT's 191 not 198 which is empty. Also IBM DTCPARMS is named IBMN DTCPARMS on TCPMAINT's 191: MAINTFILELIST A0 V 169 Trunc=169 Size=10 Line=1 Col=1 Alt=0 Cmd Filename Filetype Fm Format LreclRecords Blocks Date Time MPROUTE CONFIG T1 F 80 47 1 10/09/09 15:31:10 MPROUTES CONFIG T1 F 80 59 2 10/06/09 11:28:10 MPROUTE CONFOLD T1 F 80 58 2 8/19/09 11:13:31 PROFILE EXEC T2 V 73 54 1 8/04/09 12:04:18 MPROUTEX CONFIG T1 F 80 28 1 7/29/09 12:03:46 MPROUTEO CONFIG T1 F 80472 10 1/23/09 16:33:35 XCONFIG T1 F 80 20 1 1/23/09 14:52:04 SYSTEM DTCPARMS T1 F 80359 8 1/23/09 14:41:15 IBMN DTCPARMS T1 V 73359 4 1/15/09 14:24:33 TCPIPO DATA T1 V 73474 5 1/15/09 12:31:27 Hope this does not bring Chuckie out. Alan Altmark alan_altm...@us.ibm.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 02/22/2011 06:54 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Changing TCPIP PROFILE EXEC On Tuesday, 02/22/2011 at 06:00 EST, George Henke/NYLIC george_he...@newyorklife.com wrote: DEV 9000, 9001, 9002 are changing to 9400, 9401, 9402 Here is what I have now: TCPIP: PROFILE EXEC 'Access 198 D' 'Access 591 E' 'Access 592 F' ATT 9000 TCPIP 9000 ATT 9001 TCPIP 9001 ATT 9002 TCPIP 9002 ATT 9100 TCPIP 9100 ATT 9101 TCPIP 9101 ATT 9102 TCPIP 9102 queue EXEC TCPRUN I will pretend I didn't see that. I'm not even seeing the lack of quotes around the ATTACH commands. Not looking La la la la la la SYSTEM DTCPARMS: :nick.TCPIP :type.server :class.stack :nick.DTCVSW1 :type.server :class.stack :owner.MAINT :nick.DTCVSW2 :type.server :class.stack :owner.MAINT :nick.ROUTED:type.server :class.rip :nick.MPROUTE :type.server :class.mprout I'll assume a cut/paste error. That should be mproute. :nick.FTPSERVE :type.server :class.ftp :nick.SMTP :type.server :class.smtp Note that by putting all of those entries in SYSTEM DTCPARMS, you are effectively cancelling any entry that IBM put on the matching :type.server entry in IBM DTCPARMS. I would suggest deleting all entries except for TCPIP. At the minimum, delete the DTCVSW1 and DTCVSW2 entries. I can change the TCPIP DIRECTORY entry like so: USER TCPIP TCPIP 128M 256M ABG INCLUDE TCPCMSU OPTION QUICKDSP SVMSTAT MAXCONN 1024 DIAG98 APPLMON SHARE RELATIVE 3000 IUCV ALLOW IUCV ANY PRIORITY IUCV *CCS PRIORITY MSGLIMIT 255 IUCV *VSWITCH MSGLIMIT 65535 * CHANGE SPECIAL FROM 9104 TO 9108 PER SAM 9/30/09 SPECIAL 9108 QDIO 3 SYSTEM OSALAN LINK 5VMTCP40 491 491 RR LINK 5VMTCP40 492 492 RR LINK TCPMAINT 591 591 RR LINK TCPMAINT 592 592 RR LINK TCPMAINT 198 198 RR COMMAND ATTACH 9400 TO * 9000 COMMAND ATTACH 9401 TO * 9001 COMMAND ATTACH 9402 TO * 9002 COMMAND ATTACH 9000 TO * 9000 COMMAND ATTACH 9001 TO * 9001 COMMAND ATTACH 9002 TO * 9002 MDISK 191 3390 2258 005 540W02 MR RTCPIP WTCPIP MTCPIP Is this correct? Yes, except that COMMAND statement must be placed before any device statements. Or I can modify DTCPARMS like so: :nick.TCPIP :type.server :class.stack :attach.9400-9402 In this case you must also
Re: Changing TCPIP PROFILE EXEC
On Wednesday, 02/23/2011 at 11:09 EST, George Henke/NYLIC george_he...@newyorklife.com wrote: Alan: I have moved the COMMAND statements to the top before the INCLUDE TCPCMSU which has DEV type statements like SPOOL, CONSOLE, LINK and it IPLs CMS. Hopefully this is correct now. DIRECTXA is the final arbiter of what's valid. What's-his-name thinks he's so smart, but he's not. Not really. He's old and feeble. But the SYSTEM DTCPARMS is on TCPMAINT's 191 not 198 which is empty. Doesn't do anyone any good there; the servers don't access TCPMAINT's 191. At install time, I think you didn't perform the step 6.2.3.2.45.1253 (in the tcp/ip program directory) that populates the 198 with samples, and you didn't use the IP Wizard, which would have placed files on the 592 and the 198. Also IBM DTCPARMS is named IBMN DTCPARMS on TCPMAINT's 191: Since (a) it's on the wrong disk, and (2) it has the wrong name, it just means nothing is never ever going to read it, so it's just e-trash. IBM DTCPARMS lives on TCPMAINT 591, safe and sound, where there is a sign hanging on the door that says Warning: Shock hazard. No user serviceable parts inside. MAINTFILELIST A0 V 169 Trunc=169 Size=10 Line=1 Col=1 Alt=0 Cmd Filename Filetype Fm Format LreclRecords Blocks Date Time MPROUTE CONFIG T1 F 80 47 1 10/09/09 15:31:10 MPROUTES CONFIG T1 F 80 59 2 10/06/09 11:28:10 MPROUTE CONFOLD T1 F 80 58 2 8/19/09 11:13:31 PROFILE EXEC T2 V 73 54 1 8/04/09 12:04:18 MPROUTEX CONFIG T1 F 80 28 1 7/29/09 12:03:46 MPROUTEO CONFIG T1 F 80472 10 1/23/09 16:33:35 XCONFIG T1 F 80 20 1 1/23/09 14:52:04 SYSTEM DTCPARMS T1 F 80359 8 1/23/09 14:41:15 IBMN DTCPARMS T1 V 73359 4 1/15/09 14:24:33 TCPIPO DATA T1 V 73474 5 1/15/09 12:31:27 Hope this does not bring Chuckie out. You're killing me, George. You're just killing me. Someone bring me my pills. There's nothing like having copies of config files on your own A-disk (TCPIP DATA is a good one) so that everything works fine for you, but aeu418dk not for anyone else fdsflkjaDSLGwdo not attempt to adjust your televisioncdLJHgurglefa9ujn At one installation I saw evidence of what appeared to be human remains (cleaned up with bleach before DNA evidence could be collected), where someone tried to alter TCPIP's PROFILE EXEC or the IBM DTCPARMS file on the 591. It was never explained to my satisfaction. There was another case where someone copied the entire contents of IBM DTCPARMS onto SYSTEM DTCPARMS on the 198, apparently thinking to outfox the system. The individual has not been seen for 3 weeks now. But go ahead. Do what you want. Hey. It's not MY system. He Who Must Not Be Named IBM Blab Services office: 666.555.1212
Re: Changing TCPIP PROFILE EXEC
Alan: Please be sure your effort and words are greatly appreciated and have not been wasted. I wish I could take credit for the config, but unfortunately I am new here. Since being enlightened yesterday, I have been in touch with the z/VM and network teams here and told them no one must ever again touch TCPIP PROFILE EXEC or mess with IBM DTCPARMS. Education should not be, but often is, a painful process. Your counsel and advice are beyond measure. tyvm Alan Altmark alan_altm...@us.ibm.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 02/23/2011 01:15 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Changing TCPIP PROFILE EXEC On Wednesday, 02/23/2011 at 11:09 EST, George Henke/NYLIC george_he...@newyorklife.com wrote: Alan: I have moved the COMMAND statements to the top before the INCLUDE TCPCMSU which has DEV type statements like SPOOL, CONSOLE, LINK and it IPLs CMS. Hopefully this is correct now. DIRECTXA is the final arbiter of what's valid. What's-his-name thinks he's so smart, but he's not. Not really. He's old and feeble. But the SYSTEM DTCPARMS is on TCPMAINT's 191 not 198 which is empty. Doesn't do anyone any good there; the servers don't access TCPMAINT's 191. At install time, I think you didn't perform the step 6.2.3.2.45.1253 (in the tcp/ip program directory) that populates the 198 with samples, and you didn't use the IP Wizard, which would have placed files on the 592 and the 198. Also IBM DTCPARMS is named IBMN DTCPARMS on TCPMAINT's 191: Since (a) it's on the wrong disk, and (2) it has the wrong name, it just means nothing is never ever going to read it, so it's just e-trash. IBM DTCPARMS lives on TCPMAINT 591, safe and sound, where there is a sign hanging on the door that says Warning: Shock hazard. No user serviceable parts inside. MAINTFILELIST A0 V 169 Trunc=169 Size=10 Line=1 Col=1 Alt=0 Cmd Filename Filetype Fm Format LreclRecords Blocks Date Time MPROUTE CONFIG T1 F 80 47 1 10/09/09 15:31:10 MPROUTES CONFIG T1 F 80 59 2 10/06/09 11:28:10 MPROUTE CONFOLD T1 F 80 58 2 8/19/09 11:13:31 PROFILE EXEC T2 V 73 54 1 8/04/09 12:04:18 MPROUTEX CONFIG T1 F 80 28 1 7/29/09 12:03:46 MPROUTEO CONFIG T1 F 80472 10 1/23/09 16:33:35 XCONFIG T1 F 80 20 1 1/23/09 14:52:04 SYSTEM DTCPARMS T1 F 80359 8 1/23/09 14:41:15 IBMN DTCPARMS T1 V 73359 4 1/15/09 14:24:33 TCPIPO DATA T1 V 73474 5 1/15/09 12:31:27 Hope this does not bring Chuckie out. You're killing me, George. You're just killing me. Someone bring me my pills. There's nothing like having copies of config files on your own A-disk (TCPIP DATA is a good one) so that everything works fine for you, but aeu418dk not for anyone else fdsflkjaDSLGwdo not attempt to adjust your televisioncdLJHgurglefa9ujn At one installation I saw evidence of what appeared to be human remains (cleaned up with bleach before DNA evidence could be collected), where someone tried to alter TCPIP's PROFILE EXEC or the IBM DTCPARMS file on the 591. It was never explained to my satisfaction. There was another case where someone copied the entire contents of IBM DTCPARMS onto SYSTEM DTCPARMS on the 198, apparently thinking to outfox the system. The individual has not been seen for 3 weeks now. But go ahead. Do what you want. Hey. It's not MY system. He Who Must Not Be Named IBM Blab Services office: 666.555.1212
Re: Changing TCPIP PROFILE EXEC
Alan: OSAs 9000,1,2 are changing to OSAs 9400,1,2.when we install the z196. To restore our TCPIP PROFILE EXEC to its original state we should delete all the attaches, not just the 9000,1,2 which are changing and put them all in either the TCPIP DIRECTORY entry or DTCPARMS. A question came up though: Network managment here seems set on attaching the new OSAs 9400.1.2 not as old OSAs 9000,1,2 but as themselves, 9400,1,2 If we were to leave the PROFILE EXEC the way it is for now and just put the new OSA addresses 9400, 1,2 in the TCPIP DIRECTORY entry as themselves 9400, 1,2 (VADDR=RADDR) not as 9000,1,2 do you see any problem with this after the OSA 9000,1,2 address go away? Since neatness counts, though, I would think it preferable to just get rid of all the attaches from the TCPIP PROFILE EXEC and put them in either TCPIP DIRECTORY or DTCPARMS.. TCPIP: PROFILE EXEC 'Access 198 D' 'Access 591 E' 'Access 592 F' ATT 9000 TCPIP 9000 ATT 9001 TCPIP 9001 ATT 9002 TCPIP 9002 ATT 9100 TCPIP 9100 ATT 9101 TCPIP 9101 ATT 9102 TCPIP 9102 queue EXEC TCPRUN Alan Altmark alan_altm...@us.ibm.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 02/23/2011 01:15 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Changing TCPIP PROFILE EXEC On Wednesday, 02/23/2011 at 11:09 EST, George Henke/NYLIC george_he...@newyorklife.com wrote: Alan: I have moved the COMMAND statements to the top before the INCLUDE TCPCMSU which has DEV type statements like SPOOL, CONSOLE, LINK and it IPLs CMS. Hopefully this is correct now. DIRECTXA is the final arbiter of what's valid. What's-his-name thinks he's so smart, but he's not. Not really. He's old and feeble. But the SYSTEM DTCPARMS is on TCPMAINT's 191 not 198 which is empty. Doesn't do anyone any good there; the servers don't access TCPMAINT's 191. At install time, I think you didn't perform the step 6.2.3.2.45.1253 (in the tcp/ip program directory) that populates the 198 with samples, and you didn't use the IP Wizard, which would have placed files on the 592 and the 198. Also IBM DTCPARMS is named IBMN DTCPARMS on TCPMAINT's 191: Since (a) it's on the wrong disk, and (2) it has the wrong name, it just means nothing is never ever going to read it, so it's just e-trash. IBM DTCPARMS lives on TCPMAINT 591, safe and sound, where there is a sign hanging on the door that says Warning: Shock hazard. No user serviceable parts inside. MAINTFILELIST A0 V 169 Trunc=169 Size=10 Line=1 Col=1 Alt=0 Cmd Filename Filetype Fm Format LreclRecords Blocks Date Time MPROUTE CONFIG T1 F 80 47 1 10/09/09 15:31:10 MPROUTES CONFIG T1 F 80 59 2 10/06/09 11:28:10 MPROUTE CONFOLD T1 F 80 58 2 8/19/09 11:13:31 PROFILE EXEC T2 V 73 54 1 8/04/09 12:04:18 MPROUTEX CONFIG T1 F 80 28 1 7/29/09 12:03:46 MPROUTEO CONFIG T1 F 80472 10 1/23/09 16:33:35 XCONFIG T1 F 80 20 1 1/23/09 14:52:04 SYSTEM DTCPARMS T1 F 80359 8 1/23/09 14:41:15 IBMN DTCPARMS T1 V 73359 4 1/15/09 14:24:33 TCPIPO DATA T1 V 73474 5 1/15/09 12:31:27 Hope this does not bring Chuckie out. You're killing me, George. You're just killing me. Someone bring me my pills. There's nothing like having copies of config files on your own A-disk (TCPIP DATA is a good one) so that everything works fine for you, but aeu418dk not for anyone else fdsflkjaDSLGwdo not attempt to adjust your televisioncdLJHgurglefa9ujn At one installation I saw evidence of what appeared to be human remains (cleaned up with bleach before DNA evidence could be collected), where someone tried to alter TCPIP's PROFILE EXEC or the IBM DTCPARMS file on the 591. It was never explained to my satisfaction. There was another case where someone copied the entire contents of IBM DTCPARMS onto SYSTEM DTCPARMS on the 198, apparently thinking to outfox the system. The individual has not been seen for 3 weeks now. But go ahead. Do what you want. Hey. It's not MY system. He Who Must Not Be Named IBM Blab Services office: 666.555.1212
Re: Changing TCPIP PROFILE EXEC
On Wednesday, 02/23/2011 at 05:11 EST, George Henke/NYLIC george_he...@newyorklife.com wrote: OSAs 9000,1,2 are changing to OSAs 9400,1,2.when we install the z196. To restore our TCPIP PROFILE EXEC to its original state we should delete all the attaches, not just the 9000,1,2 which are changing and put them all in either the TCPIP DIRECTORY entry or DTCPARMS. Or use the :Exit. tag in DTCPARMS, yes. A question came up though: Network managment here seems set on attaching the new OSAs 9400.1.2 not as old OSAs 9000,1,2 but as themselves, 9400,1,2 If we were to leave the PROFILE EXEC the way it is for now and just put the new OSA addresses 9400, 1,2 in the TCPIP DIRECTORY entry as themselves 9400, 1,2 (VADDR=RADDR) not as 9000,1,2 do you see any problem with this after the OSA 9000,1,2 address go away? You can do that, sure, but you'll need to add an extra HOME and DEVICE/LINK pair to PROFILE TCPIP in order to provide the fallback you were looking for. Since neatness counts, though, I would think it preferable to just get rid of all the attaches from the TCPIP PROFILE EXEC and put them in either TCPIP DIRECTORY or DTCPARMS. But you can still do the ATTACHes yourself in an exec. Just don't use PROFILE EXEC; use the :Exit tag or TCPRUNXT EXEC instead. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Changing TCPIP PROFILE EXEC
I have to change some DEV ATTACHes in our TCPIP PROFILE Exec in preparation for new OSA ADDRs in our IODF for our new z/196. What is the best way to implement this? I suppose I can logon to TCPIP AC ( noprof and create a backup copy of the PROFILE EXEC and then change the original DEV ADDRs. Is this correct? Best Practice? Also what would the fallback be in such a situation?
Re: Changing TCPIP PROFILE EXEC
ATTACHES can be done in file yournode DTCPARMS or SYSTEM DTCPAMRS on TCPMAINT 198. *They shall never modify a PROFILE EXEC on TCPIP 191, it's IBM property;-)* And, for dynamic changes there is the CP ATTACH command and an OBEYFILE command. 2011/2/22 George Henke/NYLIC george_he...@newyorklife.com I have to change some DEV ATTACHes in our TCPIP PROFILE Exec in preparation for new OSA ADDRs in our IODF for our new z/196. What is the best way to implement this? I suppose I can logon to TCPIP AC ( noprof and create a backup copy of the PROFILE EXEC and then change the original DEV ADDRs. Is this correct? Best Practice? Also what would the fallback be in such a situation? -- Kris Buelens, IBM Belgium, VM customer support
Re: Changing TCPIP PROFILE EXEC
On Tuesday, 02/22/2011 at 04:59 EST, George Henke/NYLIC george_he...@newyorklife.com wrote: I have to change some DEV ATTACHes in our TCPIP PROFILE Exec in preparation for new OSA ADDRs in our IODF for our new z/196. What is the best way to implement this? I suppose I can logon to TCPIP AC ( noprof and create a backup copy of the PROFILE EXEC and then change the original DEV ADDRs. Is this correct? Best Practice? Are you TRYING to bring Chuckie out of hiding?!? NEVER change TCPIP's PROFILE EXEC. Ever. Ever. Your SYSTEM DTCPARMS file supports :attach. tags to identify devices. :nick.TCPIP :attach.FE08-FE0A Also what would the fallback be in such a situation? Not sure what you mean in this case, but you can leave the TCP/IP configuration and alone and simply use DEDICATE or COMMAND ATTACH statements in TCPIP's directory entry. E.g. Let us say that your OSAs are currently at 600-602 and the new ones are at 800-802. COMMAND ATTACH 800 TO * 600 COMMAND ATTACH 801 TO * 601 COMMAND ATTACH 802 TO * 602 COMMAND ATTACH 600 TO * 600 COMMAND ATTACH 601 TO * 601 COMMAND ATTACH 602 TO * 602 In that way, the DEVICE statement in PROFILE TCPIP doesn't have to change and the above sequence will try for device 800-802, but will fall back to 600-602 if 800-802 isn't there. Not perfect. For more robust logic, you code :Exit.name-of-exec in the SYSTEM DTCPARMS entry for TCPIP and use an exec to figure out which set of devices to use, possibly based on other criteria. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: Changing TCPIP PROFILE EXEC
tyvm, Alan and Kris, once again for saving my neck. DEV 9000, 9001, 9002 are changing to 9400, 9401, 9402 Here is what I have now: TCPIP: PROFILE EXEC 'Access 198 D' 'Access 591 E' 'Access 592 F' ATT 9000 TCPIP 9000 ATT 9001 TCPIP 9001 ATT 9002 TCPIP 9002 ATT 9100 TCPIP 9100 ATT 9101 TCPIP 9101 ATT 9102 TCPIP 9102 queue EXEC TCPRUN SYSTEM DTCPARMS: :nick.TCPIP :type.server :class.stack :nick.DTCVSW1 :type.server :class.stack :owner.MAINT :nick.DTCVSW2 :type.server :class.stack :owner.MAINT :nick.ROUTED:type.server :class.rip :nick.MPROUTE :type.server :class.mprout :nick.FTPSERVE :type.server :class.ftp :nick.SMTP :type.server :class.smtp TCPIP DIRECTORY ENTRY: USER TCPIP TCPIP 128M 256M ABG INCLUDE TCPCMSU OPTION QUICKDSP SVMSTAT MAXCONN 1024 DIAG98 APPLMON SHARE RELATIVE 3000 IUCV ALLOW IUCV ANY PRIORITY IUCV *CCS PRIORITY MSGLIMIT 255 IUCV *VSWITCH MSGLIMIT 65535 * CHANGE SPECIAL FROM 9104 TO 9108 PER SAM 9/30/09 SPECIAL 9108 QDIO 3 SYSTEM OSALAN LINK 5VMTCP40 491 491 RR LINK 5VMTCP40 492 492 RR LINK TCPMAINT 591 591 RR LINK TCPMAINT 592 592 RR LINK TCPMAINT 198 198 RR MDISK 191 3390 2258 005 540W02 MR RTCPIP WTCPIP MTCPIP I can change the TCPIP DIRECTORY entry like so: USER TCPIP TCPIP 128M 256M ABG INCLUDE TCPCMSU OPTION QUICKDSP SVMSTAT MAXCONN 1024 DIAG98 APPLMON SHARE RELATIVE 3000 IUCV ALLOW IUCV ANY PRIORITY IUCV *CCS PRIORITY MSGLIMIT 255 IUCV *VSWITCH MSGLIMIT 65535 * CHANGE SPECIAL FROM 9104 TO 9108 PER SAM 9/30/09 SPECIAL 9108 QDIO 3 SYSTEM OSALAN LINK 5VMTCP40 491 491 RR LINK 5VMTCP40 492 492 RR LINK TCPMAINT 591 591 RR LINK TCPMAINT 592 592 RR LINK TCPMAINT 198 198 RR COMMAND ATTACH 9400 TO * 9000 COMMAND ATTACH 9401 TO * 9001 COMMAND ATTACH 9402 TO * 9002 COMMAND ATTACH 9000 TO * 9000 COMMAND ATTACH 9001 TO * 9001 COMMAND ATTACH 9002 TO * 9002 MDISK 191 3390 2258 005 540W02 MR RTCPIP WTCPIP MTCPIP Is this correct? Or I can modify DTCPARMS like so: :nick.TCPIP :type.server :class.stack :attach.9400-9402 Is this correct? If so, which would be preferable? I do not see a fallback if I modify DTCPARMS only. But OTOH the DIRECTORY method does not look as permanent. Also why *COMMAND* in the DIRECTORY entry ATTACHes? I thought that is used only in EXECs? Also can I abbreviate the ATTACH to ATT 9400 * 9000? Also, the DIRECTORY method has a nice fallback, but what if I corrupt the TCPIP DIRECTORY entry when making the change. What is my fallback? VTAM? Alan Altmark alan_altm...@us.ibm.com Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 02/22/2011 05:19 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Changing TCPIP PROFILE EXEC On Tuesday, 02/22/2011 at 04:59 EST, George Henke/NYLIC george_he...@newyorklife.com wrote: I have to change some DEV ATTACHes in our TCPIP PROFILE Exec in preparation for new OSA ADDRs in our IODF for our new z/196. What is the best way to implement this? I suppose I can logon to TCPIP AC ( noprof and create a backup copy of the PROFILE EXEC and then change the original DEV ADDRs. Is this correct? Best Practice? Are you TRYING to bring Chuckie out of hiding?!? NEVER change TCPIP's PROFILE EXEC. Ever. Ever. Your SYSTEM DTCPARMS file supports :attach. tags to identify devices. :nick.TCPIP :attach.FE08-FE0A Also what would the fallback be in such a situation? Not sure what you mean in this case, but you can leave the TCP/IP configuration and alone and simply use DEDICATE or COMMAND ATTACH statements in TCPIP's directory entry. E.g. Let us say that your OSAs are currently at 600-602 and the new ones are at 800-802. COMMAND ATTACH 800 TO * 600 COMMAND ATTACH 801 TO * 601 COMMAND ATTACH 802 TO * 602 COMMAND ATTACH 600 TO * 600 COMMAND ATTACH 601 TO * 601 COMMAND ATTACH 602 TO * 602 In that way, the DEVICE statement in PROFILE TCPIP doesn't have to change and the above sequence will try for device 800-802, but will fall back to 600-602 if 800-802 isn't there. Not perfect. For more robust logic, you code :Exit.name-of-exec in the SYSTEM DTCPARMS entry for TCPIP and use an exec to figure out which set of devices to use, possibly based on other criteria. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: Changing TCPIP PROFILE EXEC
On Tuesday, 02/22/2011 at 06:00 EST, George Henke/NYLIC george_he...@newyorklife.com wrote: DEV 9000, 9001, 9002 are changing to 9400, 9401, 9402 Here is what I have now: TCPIP: PROFILE EXEC 'Access 198 D' 'Access 591 E' 'Access 592 F' ATT 9000 TCPIP 9000 ATT 9001 TCPIP 9001 ATT 9002 TCPIP 9002 ATT 9100 TCPIP 9100 ATT 9101 TCPIP 9101 ATT 9102 TCPIP 9102 queue EXEC TCPRUN I will pretend I didn't see that. I'm not even seeing the lack of quotes around the ATTACH commands. Not looking La la la la la la SYSTEM DTCPARMS: :nick.TCPIP :type.server :class.stack :nick.DTCVSW1 :type.server :class.stack :owner.MAINT :nick.DTCVSW2 :type.server :class.stack :owner.MAINT :nick.ROUTED:type.server :class.rip :nick.MPROUTE :type.server :class.mprout I'll assume a cut/paste error. That should be mproute. :nick.FTPSERVE :type.server :class.ftp :nick.SMTP :type.server :class.smtp Note that by putting all of those entries in SYSTEM DTCPARMS, you are effectively cancelling any entry that IBM put on the matching :type.server entry in IBM DTCPARMS. I would suggest deleting all entries except for TCPIP. At the minimum, delete the DTCVSW1 and DTCVSW2 entries. I can change the TCPIP DIRECTORY entry like so: USER TCPIP TCPIP 128M 256M ABG INCLUDE TCPCMSU OPTION QUICKDSP SVMSTAT MAXCONN 1024 DIAG98 APPLMON SHARE RELATIVE 3000 IUCV ALLOW IUCV ANY PRIORITY IUCV *CCS PRIORITY MSGLIMIT 255 IUCV *VSWITCH MSGLIMIT 65535 * CHANGE SPECIAL FROM 9104 TO 9108 PER SAM 9/30/09 SPECIAL 9108 QDIO 3 SYSTEM OSALAN LINK 5VMTCP40 491 491 RR LINK 5VMTCP40 492 492 RR LINK TCPMAINT 591 591 RR LINK TCPMAINT 592 592 RR LINK TCPMAINT 198 198 RR COMMAND ATTACH 9400 TO * 9000 COMMAND ATTACH 9401 TO * 9001 COMMAND ATTACH 9402 TO * 9002 COMMAND ATTACH 9000 TO * 9000 COMMAND ATTACH 9001 TO * 9001 COMMAND ATTACH 9002 TO * 9002 MDISK 191 3390 2258 005 540W02 MR RTCPIP WTCPIP MTCPIP Is this correct? Yes, except that COMMAND statement must be placed before any device statements. Or I can modify DTCPARMS like so: :nick.TCPIP :type.server :class.stack :attach.9400-9402 In this case you must also modify PROFILE TCPIP to change the DEVICE statement to point to 9400. You could instead :attach.9400 9000, 9401 9001, 9402 9002 If so, which would be preferable? I do not see a fallback if I modify DTCPARMS only. :attach.9400(OPT) 9000, 9401(OPT) 9001, 9402(OPT) 9002(OPT), 9000-9002(OPT) gives the same result. If you don't put OPT in there, the TCP/IP startup program won't throw an error if one of the devices if offline or the attach fails. Again, if you need more sophistication, use the :Exit. tag. Read Chapter 5 of the TCP/IP planning book for details on how to use DTCPARMS files. But OTOH the DIRECTORY method does not look as permanent. Also why *COMMAND* in the DIRECTORY entry ATTACHes? I thought that is used only in EXECs? COMMAND is a valid statement in the directory. ATTACH is not. Look in the CP Planning book. Also can I abbreviate the ATTACH to ATT 9400 * 9000? Yes, but don't. IBM has changed the abbreviations of commands. Abbreviations are for humans, not programs. Also, the DIRECTORY method has a nice fallback, but what if I corrupt the TCPIP DIRECTORY entry when making the change. What is my fallback? VTAM? VTAM? In general, no, since few systems have VTAM (and it isn't licensed on IFLs). OSA-ICC connections (preferred) or the integrated 3270 console are how you access the system in case of TCPIP death. In extreme cases, the linemode integrated console can be used. If you need to repair TCP/IP in this mode, learn to use the ifconfig commands rather than XEDIT. It's easier than using a linemode editor. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
Re: Changing TCPIP PROFILE EXEC
You probably have those :owner. tags in there for the console log. Do yourself a favor and just put a TCPRUNXT EXEC on TCPMAINT 198 that defines a common owner. Then you can remove those extra entries. Here is an example: /* TCPIP Startup Exit TCPRUNXT EXEC */ Address Command conlog = 'MAINT' /* Define user for console logs */ ESM? = 0 /* ESM on the system? */ arg calltype . returnstr = 0 If calltype = 'SETUP' then do returnstr = returnstr ':Owner.'conlog If ESM? then returnstr = returnstr ':ESM_Enable.YES' end Exit returnstr On Tue, Feb 22, 2011 at 6:00 PM, George Henke/NYLIC george_he...@newyorklife.com wrote: tyvm, Alan and Kris, once again for saving my neck. DEV 9000, 9001, 9002 are changing to 9400, 9401, 9402 Here is what I have now: *TCPIP: PROFILE EXEC* 'Access 198 D' 'Access 591 E' 'Access 592 F' *ATT 9000 TCPIP 9000 * *ATT 9001 TCPIP 9001 * *ATT 9002 TCPIP 9002 * ATT 9100 TCPIP 9100 ATT 9101 TCPIP 9101 ATT 9102 TCPIP 9102 queue EXEC TCPRUN *SYSTEM DTCPARMS:* *:nick.TCPIP :type.server :class.stack * :nick.DTCVSW1 :type.server :class.stack :owner.MAINT :nick.DTCVSW2 :type.server :class.stack :owner.MAINT :nick.ROUTED:type.server :class.rip :nick.MPROUTE :type.server :class.mprout :nick.FTPSERVE :type.server :class.ftp :nick.SMTP :type.server :class.smtp *TCPIP DIRECTORY ENTRY:* USER TCPIP TCPIP 128M 256M ABG INCLUDE TCPCMSU OPTION QUICKDSP SVMSTAT MAXCONN 1024 DIAG98 APPLMON SHARE RELATIVE 3000 IUCV ALLOW IUCV ANY PRIORITY IUCV *CCS PRIORITY MSGLIMIT 255 IUCV *VSWITCH MSGLIMIT 65535 * CHANGE SPECIAL FROM 9104 TO 9108 PER SAM 9/30/09 SPECIAL 9108 QDIO 3 SYSTEM OSALAN LINK 5VMTCP40 491 491 RR LINK 5VMTCP40 492 492 RR LINK TCPMAINT 591 591 RR LINK TCPMAINT 592 592 RR LINK TCPMAINT 198 198 RR MDISK 191 3390 2258 005 540W02 MR RTCPIP WTCPIP MTCPIP *I can change the TCPIP DIRECTORY entry like so:* USER TCPIP TCPIP 128M 256M ABG INCLUDE TCPCMSU OPTION QUICKDSP SVMSTAT MAXCONN 1024 DIAG98 APPLMON SHARE RELATIVE 3000 IUCV ALLOW IUCV ANY PRIORITY IUCV *CCS PRIORITY MSGLIMIT 255 IUCV *VSWITCH MSGLIMIT 65535 * CHANGE SPECIAL FROM 9104 TO 9108 PER SAM 9/30/09 SPECIAL 9108 QDIO 3 SYSTEM OSALAN LINK 5VMTCP40 491 491 RR LINK 5VMTCP40 492 492 RR LINK TCPMAINT 591 591 RR LINK TCPMAINT 592 592 RR LINK TCPMAINT 198 198 RR * COMMAND ATTACH 9400 TO * 9000* * COMMAND ATTACH 9401 TO * 9001* * COMMAND ATTACH 9402 TO * 9002* * COMMAND ATTACH 9000 TO * 9000* * COMMAND ATTACH 9001 TO * 9001* * COMMAND ATTACH 9002 TO * 9002* MDISK 191 3390 2258 005 540W02 MR RTCPIP WTCPIP MTCPIP Is this correct? *Or I can modify DTCPARMS like so:* *:nick.TCPIP :type.server :class.stack :attach.9400-9402 * Is this correct? If so, which would be preferable? I do not see a fallback if I modify DTCPARMS only. But OTOH the DIRECTORY method does not look as permanent. Also why *COMMAND* in the DIRECTORY entry ATTACHes? I thought that is used only in EXECs? Also can I abbreviate the ATTACH to ATT 9400 * 9000? Also, the DIRECTORY method has a nice fallback, but what if I corrupt the TCPIP DIRECTORY entry when making the change. What is my fallback? VTAM? -- Bruce Hayden z/VM and Linux on System z ATS IBM, Endicott, NY
