> 
> Thanks for the assistance.  After pulling a little more hair out
> I finally got the LPAR CTC links to
> work.  In the process I ran into a few things I still don't
> quite understand.

Well, keep your hat on! (It protects the hair, and we can't
spare any, any more!)

> When I got the CTC's properly defined,  I ran into a situation
> where I could get both sides to bring the links ready and
> set up the gateways between them but could not Ping across the
> LINK.  After trying about every order of bringing up the links
> I restarted both stacks and took the START statements for the
> DEVICEs out of the PROFILE TCPIP files on both systems.  I was
> then able to run an OBEYFILE on both sides to START the
> DEVICEs and things worked fine.
> 
> I've never run into a case where order of starting the LINKs
> gave problems.  BTW, the first TCp/IP was at Z/VM 4.4 level and
> the second was as Z/VM 5.2 level.  (It took me a while to notice
> the syntax in the 5.2 Gateway statement had changed.)

I will leave the TCPIP problems to others more knowledgeable.

> Is there a command to stop a DEVICE so you can reissue a START again
> without restarting TCP/IP?  Z/OS TCP/IP has a VARY command for this
> sort of thing.

Yup. the 2 commands you want are.... STOP and START.
You use an OBEYFILE to run them.

>From TCPIP Plng and Cust:

> 24.93 Changing the TCP/IP Configuration with the OBEYFILE Command
> 
> The OBEYFILE command allows you to make temporary dynamic changes to the
> system operation and network configuration without stopping and restarting
> the TCPIP virtual machine. You can maintain different files that contain a
> subset of the TCP/IP configuration statements and use OBEYFILE to activate
> them while TCP/IP is running.


> 24.78 START Statement
> 
> 
> Use the START statement to start a device that is currently stopped. This
> statement is usually specified at the end of the configuration file.
> 
>                                                               _ _
> >>__START__device_name____________________________________________________
> 
> Operands
> 
> device_name
>     The name of the device to start. This must be the same device_name
>     specified in a DEVICE statement.
> 


> 24.79 STOP Statement
> 
> Use the STOP statement in an obey file to stop a device that is currently
> started.
> 
>                                                               _ _
> >>__STOP__device_name_____________________________________________________
> 
> Operands
> 
> device_name
>     The name of the device to be stopped. This must be the same
>     device_name specified in a DEVICE statement.
> 


> 
> 
> Would this IOCP entry remove  the redundant paths or have I
> misread your examples again?
> 
> 
>     CHPID PATH=02,TYPE=CNC,PARTITION=(ESA11,ESA12,IFL),SHARED
>     CHPID PATH=03,TYPE=CTC,PARTITION=(ESA11,ESA12,IFL),SHARED
>     CNTLUNIT CUNUMBR=0401,PATH=(02),UNIT=SCTC,UNITADD=((00,32)),CUADD=1
>     CNTLUNIT CUNUMBR=0501,PATH=(03),UNIT=SCTC,UNITADD=((00,32)),CUADD=1
>     CNTLUNIT CUNUMBR=0402,PATH=(02),UNIT=SCTC,UNITADD=((00,32)),CUADD=2
>     CNTLUNIT CUNUMBR=0502,PATH=(03),UNIT=SCTC,UNITADD=((00,32)),CUADD=2
>     CNTLUNIT CUNUMBR=0403,PATH=(02),UNIT=SCTC,UNITADD=((00,32)),CUADD=3
>     CNTLUNIT CUNUMBR=0503,PATH=(03),UNIT=SCTC,UNITADD=((00,32)),CUADD=3
>     IODEVICE ADDRESS=(0400,32),CUNUMBR=(0401),UNITADD=00,                 X
>                   UNIT=SCTC,PART=(ESA11)
>     IODEVICE ADDRESS=(0420,32),CUNUMBR=(0402),UNITADD=00,                 X
>                   UNIT=SCTC,PART=(ESA11,ESA12)
>     IODEVICE ADDRESS=(0440,32),CUNUMBR=(0403),UNITADD=00,                 X
>                   UNIT=SCTC,PART=(ESA11,ESA12,IFL)
>     IODEVICE ADDRESS=(0500,32),CUNUMBR=(0501),UNITADD=00,                 X
>                   UNIT=SCTC,PART=(ESA11,ESA12,IFL)
>     IODEVICE ADDRESS=(0520,32),CUNUMBR=(0502),UNITADD=00,                 X
>                   UNIT=SCTC,PART=(ESA12,IFL)
>     IODEVICE ADDRESS=(0540,32),CUNUMBR=(0503),UNITADD=00,                 X
>                   UNIT=SCTC,PART=(IFL)
> 

Yes, that looks fine. Basically, once you have a connection 
from LPAR-1 to LPAR-2, with devices at both ends, why bother 
defining MORE connections from LPAR-2 to LPAR-1. :-)

Good luck,
Shimon

Reply via email to