Channel-to-channel
The awsctc device manager provides channel-to-channel (CTC) functions using TCP/IP communication paths. As shown in Figure 16-1, the connection can be within the same zPDT instance, between zPDT instances on the same machine, or between zPDT instances on different machines. Among other functions, CTC can be used by z/OS for GRS “rings”, NJE connections, XCF, TCP/IP connections, and so forth.
Figure 16-1 CTC links for zPDT
The awsctc device manager emulates IBM 3088-4 (or 3088-8) control units and devices.1 The 3088 is an older product that provided the “middle” function for connecting two channels to each other. Each channel saw the 3088 as a control unit that provided a number of devices (each of which was a connection path). Modern systems have this control unit function integrated with the channels, and physical 3088 boxes are no longer used. However, the logical function has not changed.
The devmap stanza for awsctc appears as follows:
[manager]
name awsctc 75
device E40 3088 3088 ctc://otherhost:3088/E42
device E43 3088 3088 ctc://192.168.1.90:3089/E43
The last parameter of the device statement contains three elements:
•A TCP/IP address (in dotted decimal form or as a name that can be resolved by Linux).
•Following a colon, a TCP/IP port number that is to be used on both the local and other system. The same port number is used on both ends of the connection.2 If multiple CTC connections are defined a different port number must be specified for each connection.
•Following a slash, the device number (address) of the corresponding CTC device on the remote system. To specify this, you must know how the devmap is defined on the other system. The same device number is often used at both ends, but this is not required.
An example of a simple connection between two zPDT instances in two different machines is shown in Figure 16-2.
Figure 16-2 Simple two-system CTC definition
In this example, two separate zPDT instances are shown. Because they are separate instances, the CUNUMBR (100 in the example) can be the same in both definitions (but there is no requirement to do this, of course). Both instances elected to use the same device number (E40) for the CTC device, although there is no requirement to do this. Both ends of the connection must specify the same port number (3088 in the example). Each definition specifies the IP address of the other base Linux system.
Devmap notes
Although the "ctc://" is optional, if a protocol is specified it must be "ctc". The “well known” port numbers below 1024 cannot be used; the port number must be in the range of 1024 and 65535. The IP address string cannot be specified with an awsmount command.
Each CTC address must be defined. A real 3088 had multiple device numbers defined in blocks of 8, 16, 32, or 64 devices. For example, a 3088-4 had 16 devices starting at a specified address. The emulated CTC does not do this. Each specific device number must be defined.
Status display
The awsstat command may be used to display the status of the CTC device. When the device’s peer is not yet available, the status flips between connecting and accepting. After the peer is available, the status changes to either Connected or Accepted. The Accepted side is considered the A side for protocol conflict resolution. This generally does not make any difference to the user. After data begins to flow, the Accepted/Connected is shortened to A or C and the number of send/receive bytes is displayed.
16.1 z/OS use example
Configurations using CTC can be complex. We have taken a basic NJE example, as shown in Figure 16-3.
Figure 16-3 Trivial NJE setup
The JES2PARM data for system AAA might include the following lines:
NJEDEF DELAY=360,LINENUM=2,JRNUM=2,JTNUM=2,NODENUM=2,OWNNODE=1,
PATH=1,RESTTOL=100,RESTMAX=8000000,RESTNODE=100,SRNUM=2,
STNUM=2,MAILMSG=YES,TIMETOL=1440
LINE(1) UNIT=E40,TRANSPAR=YES
NODE(1) NAME=AAA,PATHMGR=NO
NODE(2) NAME=BBB,PATHMGR=NO
CONNECT NODEA=AAA,NODEB=BBB
The JESPARM data for system BBB might include the following lines:
NJEDEF DELAY=360,LINENUM=2,JRNUM=2,JTNUM=2,NODENUM=2,OWNNODE=2,
PATH=1,RESTTOL=100,RESTMAX=8000000,RESTNODE=100,SRNUM=2,
STNUM=2,MAILMSG=YES,TIMETOL=1440
LINE1 UNIT=E40,TRANSPAR=YES
NODE(1) NAME=AAA,PATHMGR=NO
NODE(2) NAME=BBB,PATHMGR=NO
CONNECT NODEA=AAA,NODEB=BBB
These examples assume that device number E40 is defined in z/OS as a CTC device. (This is true for current z/OS AD-CD systems.) Be careful to use the IP address of the remote Linux system (and not the remote z/OS system) in the devmaps.
The devmap for system AAA might contain the following stanza:
[manager]
name awsctc 300
device E40 3088 3088 ctc://192.168.1.83:3088/E40
The devmap for system BBB might contain the following stanza:
[manager]
name awsctc 300
device E40 3088 3088 ctc://192.168.1.63:3088/E40
The status of the CTC connection can be monitored with the awsstat command:
$ awsstat E40 (use the correct device number, of course)
The device status usually starts as connecting or accepting, and later switches to connected or accepted. This may take some time. After the connection is accepted and used, the status displays byte counts, such as C-160/162.
We found that the best approach is to wait until the CTC link is established before IPL ing z/OS. The link can be checked with the awsstat E40 command (using the correct device number for your CTC, of course). This normally takes only a few seconds, but can take longer in rare cases. We then needed to issue commands on each JES2 to make the connection operational:
$S N,LINE1 (sometimes needed)
$S LINE1
A job submitted on system AAA could be directed to system BBB for execution by the following JCL:
//MYJOB JOB 1,OGDEN,MSGCLASS=X,USER=IBMUSER
// XMIT DEST=BBB
//MYJOB2 JOB 1,OGDEN.MSGCLASS=X,USER=IBMUSER
//STEP1 EXEC PGM=IEFBR14
Notice the two JOB statements in this example. The first is needed to “introduce” the XMIT statement into the job stream. The XMIT statement sends everything after it to the indicated node, including the second JOB statement. The first JOB statement (before the XMIT) is not sent to the remote node.
The following JES2 commands might be useful when working with this NJE connection:
$DCONNECT (very useful status display)
$S LINE(1)
$S N,LINE1 (discover dynamic connections)
$D NODE(*)
$D LINE
$D DESTID(*)
$D PATH(*)
$P LINE(1) (stop line)
$E LINE(1) (reset line)
$D NJEDEF (display NJE definitions)
$N,D=BBB,’$D NJEDEF’ (send JES2 command to other node)
A JES2 cold start may be necessary to enable NJE changes to JES2PARM. You need to stop the line, $P LINE(1), when stopping JES2. If the $P is not effective, try $E LINE(1) followed by $P LINE(1).
16.2 Multiple instances and z/VM
The following material outlines several uses of CTC connections with two instances of z/VM.3 This material is intended as a general overview and does not provide complete step-by-step instructions for implementation and usage. It is very unlikely that all the links shown in this example will be present in any practical system.
16.2.1 Devmaps
Three devmaps are needed for these examples. One is for a group controller (for shared devices) and two are for the z/VM instances. Many of the choices are arbitrary.
Group controller (ibmgroup)
[system]
members ibmsys1 ibmsys2
3270port 3270
[manager]
name aws3274 0002
device 0020 3279 3274
device 0021 3279 3274 # more devices could be included
[manager]
name awsosa 0009 --path=A0 --pathtype=OSD --tunnel_intf=y
device 0E00 osa osa
device 0E01 osa osa
device 0E02 osa osa
ibmsys1 instance
[system]
memory 1024m
processors 1
group ibmgroup
[manager]
name awsckd 0001
device 1000 3390 3990 /z1/540res #unshared disks
device 1001 3390 3990 /z1/540spl
device 1002 3390 3990 /z1/540pag
device 1003 3390 3990 /z1/540w01
device 1004 3390 3990 /z1/540w02
[manager]
name awsctc 0075
device 700 3088 3088 ctc://localhost:3700/700 #for TCPIP
device 700 3088 3088 ctc://localhost:3701/701 #for TCPIP
device 710 3088 3088 ctc://localhost:3710/710 #for TSAF
device 720 3088 3088 ctc://localhost:3720/720 #for ISLINK
device 740 3088 3088 ctc://localhost:3740/740 #for RSCS
ibmsys2 instance
[system]
memory 1024m
processors 1
group ibmgroup
[manager]
name awsckd 0001
device 1000 3390 3990 /z2/540res #unshared disks
device 1001 3390 3990 /z2/540spl
device 1002 3390 3990 /z2/540pag
device 1003 3390 3990 /z2/540w01
device 1004 3390 3990 /z2/540w02
[manager]
name awsctc 0075
device 700 3088 3088 ctc://localhost:3700/700 #for TCPIP
device 700 3088 3088 ctc://localhost:3701/701 #for TCPIP
device 710 3088 3088 ctc://localhost:3710/710 #for TSAF
device 720 3088 3088 ctc://localhost:3720/720 #for ISLINK
device 740 3088 3088 ctc://localhost:3740/740 #for RSCS
Description
Notice that each instance has its own copy of the z/VM disks; they are in separate directories: /z1 and /z2.
ISLINK
An ISLINK creates an ISFC (Inter-System Facility for Communications) connection. It is the easiest link because it involves only CP commands and does not require a virtual machine or userid. The VM system identifiers of the two connected systems must be different. Using the devmaps shown above, the following commands (issued by MAINT, for example) activate the link:
CP ACTIVATE ISLINK 0720 (command on ibmsys1)
CP ACTIVATE ISLINK 0720 (command on ibmsys2)
This should result in the message HCPALN2702I Link 0720 came up. The command Q ISLINK can be used to display the status of the connection.
TSAF
TSAF is an older function and probably would not be used if ISFC is available. To try it, use commands such as the following (issued by MAINT on both systems):
CP XAUTOLOG TSAFVM
CP ATT 0710 TSAFVM
Then, log on to TSAFVM and enter ADD LINK 0710 on both sides. The status of the links can be displayed with Q LINKS ALL.
RSCS
RSCS can be more complicated. The RSCS product is not enabled by default. You can check this with the command Q PRODUCT STATE ENABLED. If RSCS is not in the list, it can be enabled (using MAINT) by the command SERVICE RSCS ENABLE followed by PUT2PROD.
A configuration file is necessary on each system. The configuration files are placed on the RSCS 191 disk with the name RSCSTCP CONFIG. An example for each system might be as follows:
(for ibmsys1)
LOCAL IBMSYS1 * RSCS
LINKDEFINE IBMSYS2 TYPE NJE LINE 740 QUEUE PRI NODE IBMSYS2
PARM IBMSYS2 STREAMS=2 MAXU=2 MAXD=10 LISTPROC=NO TA=1 TAPARM='TH=100'
AUTH * OPERATOR * CP
AUTH * MAINT * CP
(for ibmsys2)
LOCAL IBMSYS2 * RSCS
LINKDEFINE IBMSYS1 TYPE NJE LINE 740 QUEUE PRI NODE IBMSYS1
PARM IBMSYS1 STREAMS=2 MAXU=2 MAXD=10 LISTPROC=NO TA=1 TAPARM='TH=100'
AUTH * OPERATOR * CP
AUTH * MAINT * CP
After the configuration files are available, start RSCS with the command XAUTOLOG GCS (issued on both systems). After RSCS starts, issue the command SMSG RSCS START IBMSYS1 on ibmsys2 and SMSG RSCS START IBMSYS2 on ibmsys1. The status of the RSCS connection can be displayed with SMSG RSCS Q SY.
TCP/IP
TCP/IP requires a pair of CTC links, one for read and one for write. The easiest way to set up TCPIP for z/VM is with IPWIZARD. With this you must assign host names and domain names; in an isolated environment these can be arbitrary names. For an isolated environment with only two nodes the gateway address does not matter; you might use 10.1.1.1.4 Use CTC0 as the interface name and address 0700 (from our sample devmap). We assigned IP address 10.1.1.2 to ibmsys1 and 10.1.1.3 to ibmsys2, and used a mask of 255.255.255.0. The configuration dialog includes positional parameters to indicate which device to use as the read channel and which to use as the write channel. This parameter could be 0 on ibmsys1 and 1 on ibmsys2. The status of TCPIP can be checked by:
VMLINK TCPMAINT 592
NETSTAT DEVL
You can force TCPIP to restart with the following commands:
FORCE TCPIP
XAUTOLOG TCPIP
1 These are parallel channel control units. ESCON and FICON CTC operation are not emulated.
2 We use ports 3088 and 3089 for these examples because it is easy to remember. There is nothing special about this port number.
3 Thanks to Bruce Hayden, of the Washington Systems Center, for this material.
4 Remember that the default address of the tunnel connection to the base Linux is 10.1.1.1. This default is used in the sample devmap.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.