Channel-to-channel
The awsctc device manager provides channel-to-channel (CTC) functions by using TCP/IP communication paths. As shown in Figure 16-1, the connection can be within the same Independent Software Vendor (ISV) IBM Z Program Development Tool (IBM zPDT)
(ISV zPDT) instance, between ISV zPDT instances on the same machine, or between
ISV zPDT instances on different machines. Among other functions, CTC can be used by z/OS for global resource serialization (GRS) “rings”, Network Job Entry (NJE) connections, Cross-System Coupling Faciity (XCF), TCP/IP connections, and so forth. Typically, the usage is between separate personal computer (PC) machines.
Figure 16-1 CTC links for ISV 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. This control unit function is integrated with the channels into modern systems, and physical 3088 boxes are no longer used. However, the logical function has not changed.
The device map (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 number, you must know how the devmap is defined on the other system. The same device number is often used at both ends, but it is not required. The numbers should correspond to CTC devices in the z/OS I/O definitions that are being used.
An example of a simple connection between two ISV 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 ISV zPDT instances are shown. Both instances use the same device number (E40) for the CTC device, although there is no requirement to do so. 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 ctc:// is optional, if a protocol is specified, it must be ctc. The port numbers below 1024 cannot be used, so the port number must be in the range of 1024 - 65535. The IP address string cannot be specified with an awsmount command.
Each CTC address must be defined. An example 3088 had multiple device numbers that were 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 use this setup. Each specific device number must be defined.
Status display
You can use the awsstat command to display the status of the CTC device. When the device’s peer is not 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 status does not make any difference to the user. After data begins to flow, accepted/connected is shortened to A or C and the number of send/receive bytes displays.
16.1 ISV z/OS usage example
Configurations that use CTC can be complex. Here is 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 situation is true for current z/OS Application Development Controlled Distribution (ADCD) systems.) Use the IP address of the remote Linux system (and not the remote z/OS system) in the devmaps.
 
Important: The time-of-day (TOD) on the two systems (in this example) must be within a few seconds of each other or the CTC connection cannot be opened.
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.)
The device status usually starts as connecting or accepting, and later switches to connected or accepted. This task might 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 performing an initial program load (IPL) of z/OS. The link can be checked with the awsstat E40 command (by using the correct device number for your CTC). This task normally takes only a few seconds, but can take longer in rare cases. Then, issue commands on each Job Entry Subsystem (JES) 2 to make the connection operational:
$S N,LINE1 (Sometimes needed. We needed it.)
$S LINE1
A job that is submitted on system AAA can be directed to system BBB for running 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 (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, which is an important command)
$E LINE(1) (Reset line.)
$D NJEDEF (Display NJE definitions.)
$N,D=BBB,’$D NJEDEF’ (Send a JES2 command to the other node.)
A JES2 cold start might be necessary to enable NJE changes to JES2PARM. You must stop the line $P LINE(1) when stopping JES2. If the $P is not effective, try $E LINE(1) followed by $P LINE(1).
When stopping JES2 activity (to prepare for a z/OS shutdown, for example), any started NJE lines must be stopped or JES2 does not end.
 
Tip: If a CTC operation is defined in the devmap, as shown in this example, but the TCP/IP connection fails or does not start, there will be periodic warning messages from ISV zPDT. If the situation exists for an extended period, there can be an excessive number of these messages.
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 unlikely that all the links that are shown in this example will be present in any practical system. The details that are shown here are from an older ISV zPDT and z/VM. A more modern configuration has not been tried.
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 TCP/IP
device 700 3088 3088 ctc://localhost:3701/701 #for TCP/IP
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 TCP/IP
device 700 3088 3088 ctc://localhost:3701/701 #for TCP/IP
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
Each instance has its own copy of the z/VM disks, and they are in separate directories (/z1 and /z2).
ISLINK
An ISLINK creates an Inter-System Facility for Communications (ISFC) connection. It is the easiest link to use because it involves only CP commands and does not require a virtual machine (VM) or user ID. The VM system identifiers of the two connected systems must be different. Using the devmaps that are 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 command should result in the message HCPALN2702I Link 0720 came up. The command Q ISLINK can be used to display the status of the connection.
Transparent Services Access Facility
Transparent Services Access Facility (TSAF) is an older function and that is not used if ISFC is available. To try it, use commands such as the following ones (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.
Remote Spooling Communications Subsystem
Remote Spooling Communications Subsystem (RSCS) can be more complicated. The RSCS product is not enabled by default. You can check its status with the command Q PRODUCT STATE ENABLED. If RSCS is not in the list, it can be enabled (with user MAINT) by using 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 TCP/IP for z/VM is with IPWIZARD. With IPWIZARD, you must assign hostnames and domain names. In an isolated environment, these names can be arbitrary. For an isolated environment with only two nodes, the gateway address does not matter, so 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 TCP/IP can be checked by running the following commands:
VMLINK TCPMAINT 592
NETSTAT DEVL
You can force TCP/IP to restart by running the following commands:
FORCE TCPIP
XAUTOLOG TCPIP
 

1 These units were parallel channel control units. ESCON and FICON CTC operation are not emulated.
2 We use ports 3088 and 3089 for these examples because they are easy to remember. There is nothing special about these port numbers.
3 Thanks to Bruce Hayden of the Washington Systems Center for this material.
4 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.
Reset
18.216.27.91