Distributed Dynamic VIPA
With Dynamic Virtual IP Addressing (DVIPA), you can concurrently run identical setups on different systems in your sysplex, and have TCP/IP, optionally with the help of WLM, distribute the client connections among these systems.
As Debug Manager works together with IBM Explorer for z/OS to allow remote debugging from Eclipse
clients, the distributed DVIPA supported by z/OS Explorer is also available with Debug Manager, but with the following considerations:
- Debug Manager only communicates with z/OS Explorer’s RSED started task that is active on the same system. This implies that a Debug Manager started task (DBGMGR) must be active on each system of your sysplex where RSED is active.
- Debug Manager only supports debugging a program
that is active on the same system. This implies that jobs submitted from the Eclipse client must
stay on the system that the client is connected to. This can be achieved by adding the
SYSAFF=*
option to the JOB card of the JCL. - Unlike in z/OS Explorer where TCP/IP can choose
which system a user will connect to, the client connection to Debug Manager must be sent to the system that the user is
active on. To achieve this, each Debug Manager must
use a unique external port (the
CLIENT
variable in the started task). - Each of the unique Debug Manager ports must be
defined to TCP/IP in the
VIPADISTRIBUTE PORT
statement.
Unique external ports
When a remote debug session is started, Debug Manager informs the Eclipse client about the port that it is listening at. In a distributed DVIPA scenario, this port must be unique in the sysplex so that the Sysplex Distributor can use this to send the client connection to the correct system.
You can use a started task JCL per system, and use a unique port number in each JCL to ensure
that each Debug Manager has a unique external port. A
system symbol that holds the unique port number for that system can be used if you want to share the
started task JCL across the systems.
- If you already have a system symbol with a numeric value that is unique per system, for example,
&SYSCLONE
, you can make it part of theCLIENT
port number definition in the started task JCL like in the following example://DBGMGR PROC PRM=, // LEPRM='RPTOPTS(ON)', // TZ='EST5EDT', // CLIENT=53&SYSCLONE, // HOST=5336, // HLQ=EQAW
- Or you can use sample JCL
SEQASAMP(EQADVIPA)
to create system symbolEQADBM
that holds the unique port number, and then referenceEQADBM
in the started task JCL://DBGMGR PROC PRM=, // LEPRM='RPTOPTS(ON)', // TZ='EST5EDT', // CLIENT=&EQADBM, // HOST=5336, // HLQ=EQAW
Note: TheEQADBM
system symbol must exist before the Debug Manager started task (DBGMGR) is started. For example, you can defineEQADVIPA
as started task to start it early in your IPL sequence.
Sample setup
In this example, the TCP/IP definitions for an existing z/OS Explorer distributed DVIPA setup are extended with
Debug Manager ports 5331 and 5332 added to the
definition. For more information about the original setup, see the “Distributed Dynamic VIPA” section in the “TCP/IP
considerations” chapter of the IBM Explorer for z/OS Host Configuration Reference Guide.