Installing the 2016 Sysplex Extensions
 
Important: This chapter is not intended as an introduction to z/OS sysplex concepts or operation. We assume that readers understand the basic concepts and terminology that is involved with z/OS sysplex use. For more information about Parallel Sysplex, see Chapter 1, “Introduction” on page 1.
This chapter describes the installation of the zPDT 2016 Sysplex Extensions package that can be downloaded from the Additional Materials section for this Redbooks document at the following ITSO website:
This document provides step-by-step instructions to help you use the package to turn your single-system ADCD into a Parallel Sysplex1.
Reminder: This release of the zPDT Sysplex Extensions is based on the May 2015 ADCD release. Although it might be possible to use it with other ADCD releases, small adjustments must be made to accommodate the changing volume names and other possible small changes between ADCD releases.
This chapter includes the following topics:
 
4.1 Implementing a sysplex under zPDT
Having described in Chapter 3, “Sysplex configurations” on page 17 the reasons why you might want to use a sysplex under zPDT and some of the benefits of sysplex, this chapter helps you combine your ADCD monoplex system with the 2016 Sysplex Extensions package to create your sysplex.
The following configurations are supported:
•Parallel sysplex that is running under IBM z/VM®
•Base sysplex that is running under z/VM
•Base sysplex that is running “native” under z/PDT, spread over two PCs
We assume that most people that are interested in running a sysplex under zPDT want a Parallel Sysplex. Therefore, the primary installation path covers all of the required steps to turn your ADCD system into a two-way Parallel Sysplex.
However, that path also caters for most of the steps that are required for a base sysplex. Therefore, all users that are interested in any form of sysplex under zPDT should follow the installation steps that are described in 4.2, “Implementation overview” on page 36 and 4.3, “Setup steps” on page 40.
If your objective is to have a base sysplex, you also should complete the steps that are described in 4.5, “Other steps for base sysplex under z/VM” on page 76 or in 4.6, “Implementing a base sysplex without z/VM” on page 79, as appropriate.
4.2 Implementation overview
One of our objectives with this package was to make its installation as easy as possible. It is not intended as a vehicle to help you learn how to set up a sysplex; rather, it is intended as a tool to help you create a data sharing Parallel Sysplex environment quickly and with as little specialist knowledge as possible. We also wanted to make it easy for you to easily switch back to a standard ADCD environment if you wanted.
Therefore, we wanted to make the package as self-contained as possible and minimize the number of changes you must make to your environment to get this sysplex up and running. This approach also contributes to the objective of making it easier to revert to a standard ADCD environment.
 
Note: For more information about zPDT and ADCD, see IBM zPDT Guide and Reference: System z Personal Development Tool, SG24-8205, which is available at this website:
We strongly recommend that you review and are familiar with the contents of that book before you start the implementation of the 2016 Sysplex Extensions.
Before you start the installation, an overview of the start-to-end process is valuable. The implementation steps are summarized in this section. For more information about each step, see 4.3, “Setup steps” on page 40. Unless otherwise noted, all the new PDS members that are described are created in USER.PARMLIB, USER.PROCLIB, and so forth.
The following summarized tasks are performed to install the 2016 Sysplex Extensions:
1. Install the base ADCD z/OS system.
You must be familiar with the operation of a z/OS system before you move to a sysplex configuration. If you do not have an ADCD system up and running, you must implement a standard ADCD monoplex system.
 
Note: This chapter covers the basic z/OS environment only. The implementation of the DB2 data sharing group is described in Chapter 5, “Sample DB2 data sharing environment” on page 95 and the CICSplex environments implementation is described in Chapter 6, “Sample CICSplex” on page 103.
2. Install z/VM if your objective is to create a Parallel Sysplex or a base sysplex that is running under z/VM. To gain some experience with running z/OS under z/VM, you can run your ADCD system under z/VM before moving to sysplex mode.
3. Download the volumes that are provided as part of the zPDT 2016 Sysplex Extensions package. The volume serial numbers, virtual address that we used for them, and a brief description of the contents of each volume are listed in Table 4-1.
Table 4-1 Volumes that are delivered by zPDT 2016 Sysplex Extensions package
Volser
Device Number
Use
CF0001
AB0
Couple data sets (CDSs) for Base and Parallel Sysplex.
PDSs containing sample JCL, parmlib, Proclib, and other required members.
CICS01,
CICS02
AB1
AB2
SMS-managed volumes containing data sets required by the CICSplex subsystems that are provided by this package.
DB2001, DB2002
AB3
AB4
SMS-managed volumes containing the data sets required by the DB2 data sharing group that is provided by this package.
In addition to the volumes that you download, there are several volumes that you must create, initialize, and populate with system-specific data sets. Those volumes are listed in Table 4-2. In this step, you use the zPDT alcckd command to create the Linux data sets that contain the z/OS volumes. In a later step, the volumes are initialized, and then the data sets are allocated on those volumes.
Table 4-2 Volumes that must be created and initialized
Volser
Device Number
Use
F1PAGX
F1PAGY
F1PAGZ
AB5
AB6
AB7
Page data sets for S0W2 system.
F1SYS2
AB8
System-specific data sets for the S0W2 system
WORK01
AB9
Work volume
 
Tip: If you experience PGT004 wait states in z/VM, it might be that you must add more paging volumes to z/VM. The z/VM IBM Knowledge Center contains the information that is needed to help you update z/VM to inform it of the new paging volumes.
We encountered HCPPGT401I and HCPPGT400I messages on the VM OPERATOR console when we started all of the CICS address spaces on both systems. These messages are pre-cursors to wait states that are caused by lack of paging space.
4. Before you change your working system, it is a good idea to create a known restart point. For more information about creating that point, see 4.3.4, “Establish a known restart point” on page 44.
5. After you download and create the 2016 Sysplex Extensions volumes, update your zPDT device map (devmap) file to add the new DASD volumes. We also suggest adding commands to your devmap file to automatically start more x3270 sessions. Because you are running z/VM and another z/OS instance, it is likely that you need more 3270 sessions than you have now. You also must set up the OSA definitions.
6. The Parallel Sysplex environment that we provide with this package uses two z/OS virtual machines that are called S0W1 and S0W2, and two Coupling Facility Virtual Machines that are called CFCC1 and CFCC2. All of these virtual machines are included in the VM directory that is provided with the ADCD z/VM package. A small change to the VM directory is required to identify the volumes that contain the couple data sets (CDSs).
7. When you use the zPDT alcckd command to allocate the new DASD volumes, the system creates Linux files that are internally formatted to resemble a CKD DASD device. However, at this stage, they do not have a volser; the device resembles a new disk that was not yet initialized. In this step, you use ICKDSF to start the volumes that are listed in Table 4-2 on page 37.
8. Most of the data sets on the volumes that you download are cataloged in user catalogs. To make those catalogs and the data sets that they reference available to your systems (in monoplex mode and when running in sysplex mode), you must IMPORT CONNECT the new user catalogs and create ALIASes for those catalogs.
9. Create the system-specific system data sets (Paging, VIO, SMF, and LOGREC) for system S0W2.
10. The ADCD naming convention of the paging data sets is not supportive of a sysplex environment and the use of system symbols. However, they use the entire volume, which leaves no room to allocate new data sets with more sysplex-appropriate names. Therefore, in this step we delete the page data sets and replace them with smaller data sets that use the same names (for compatibility purposes), and a set that uses the new naming convention.
11. Clone HFS and zFS instance-specific file systems for the second (S0W2) system.
12. Starting with z/OS 2.1, the z/OS Health Checker is started automatically. It also uses a data set to carry information from one IPL forward to the next. In this step, we allocate the S0W2 copy of that data set to avoid a JCL ERROR when the Health Checker is started on S0W2.
13. The 2016 Sysplex Extensions package provides a new set CDSs to be used in place of those CDSs that are provided by the standard ADCD deliverable. Although CDSs that are not cataloged in the master catalog can be used, this option is not the preferred option. In this step, we cataloged again the 2016 Sysplex Extensions-provided CDSs in your master catalog.
14. The ADCD-provided SMS configuration only knows about the S0W1 system and is not aware of the sysplex name. In this step, we configure SMS (by using the ISMF panels) to recognize the sysplex and the second system name (S0W2). You also must define two data classes for System Logger (LOGR) data sets and one for DB2, a new storage class for CICS and DB2 runtime data sets (logs, journals, and so on), and new storage groups for the CICS and DB2 volumes. You also must update the ACS routines to assign the appropriate SMS objects to each data set.
15. The JES2 parms must be altered to define a Multi-Access Spool (MAS) system with two members (S0W1 and S0W2). In this step, you update a member that is used by your system, so you must be careful not to create any syntax errors that can stop your current system from starting.
16. Because we wanted to give you the flexibility to switch back and forth between sysplex mode and monoplex mode, we attempted to isolate all parmlib changes to a new set of members in USER.PARMLIB, rather than changing any of the members in ADCD.xxxx.PARMLIB or SYS1.PARMLIB. In this step, you copy the 2016 Sysplex Extensions-provided parmlib members to USER.PARMLIB or to SYS1.IPLPARM (in the case of the LOADxx member). In general, there is only one new member for each type. In cases where different values were required, we used the following suffixes:
 – BS : Base sysplex under z/VM
 – PS : Parallel sysplex under z/VM
 – ST : Base sysplex spread across two or more PCs
17. Create PROCLIB members for SHUTSYS, VTAMPS, and TCP/IP.
18. Create TCPPARMS members as described later.
19. Create VTAMLST members for ATCCONPS, ATCSTRPS, and OSATRLx.
20. IPL the first member of your new sysplex.
21. Submit a job to define the log streams for LOGREC, OPERLOG, Health Checker, RRS, and SMF.
Complete the following steps if your objective is to have a base sysplex environment that is running under z/VM:
1. Because a base sysplex does not have a coupling facility (CF), it uses CTCs for inter-system XCF communication. For ease of operation, define the CTCs in the VM directory.
2. Another aspect that is related to the lack of a coupling facility is GRS. Because there is no CF, GRS must run in Ring mode rather than Star mode. The IEASYSxx member must be updated to reflect this different mode.
3. When RRS is running in a Parallel Sysplex, all the RRSs in the sysplex normally are in the same RRS group, meaning that they all share a set of log streams. In a base sysplex, it is not possible to share log streams across systems. Therefore, the Start command for RRS must be changed to specify a different group name for each system.
For a base sysplex that spans more than one PC, the following steps are required (in addition to those steps for a base sysplex running under z/VM):
1. Create a Linux shared file environment.
2. Create a second zPDT system (on another PC) with basic Linux and zPDT.
3. Create a devmap that points to the shared files on the “first” Linux system for all the 3390 volumes.
4. Add CTC definitions to the devmaps on both systems.
5. Add STP definitions to the devmaps on both systems.
6. Remember to start the zPDT STP function on each Linux system before starting zPDT. zPDT fails if the devmap includes STP definitions and the STP function is not running when zPDT is started.
4.3 Setup steps
This section provides detailed descriptions of the steps that are required to use the 2016 Sysplex Extensions to create a Parallel or base sysplex. Most of the steps are common to both types of sysplexes (when run under z/VM). A few extra steps are required to enable the base sysplex under z/VM. Those steps are described in 4.5, “Other steps for base sysplex under z/VM” on page 76.
Before you start working on these steps, we recommend printing Table 4-5 on page 75. That table includes a checklist that you can use to track your progress through the implementation steps. It is also helpful in ensuring that you do not miss any steps.
4.3.1 Installing the base ADCD system
We assume that you are familiar with ADCD and likely have an ADCD-based z/OS system up and running in monoplex mode. If you do not, we strongly recommend that you do so now (by using the standard ADCD documentation that is available at this website:
You also should use IBM zPDT Guide and Reference: System z Personal Development Tool, SG24-8205, which is available at this website:
You also should be familiar with the operation and configuration of that system before extending it (by using this package) to a sysplex.
We used the ADCD May 2015 z/OS 2.1 release as the base for this package. This release included the following volumes:
•F1RES1
•F1RES2
•F1SYS1
•F1USS1
•F1USS2
•F1PAGA
•F1PAGB
•F1PAGC
•F1PRD1
•F1PRD2
•F1PRD3
•F1BBN1
•F1CFG1
These volumes provide z/OS and the common products, such as compilers.2 We also recommend that you install the single-pack z/OS system (volume SARES1). This system can prove invaluable if you make a mistake and end up with a system that does not IPL.
Also, if you expect to need to install service on z/OS, you should restore the two DLIB volumes: F1DIS1 and F1DIS2. We also installed the volumes that are used by CICS V5.2 (F1C521) and DB2 V11 (F1DBB1 and F1DBB2); however, they are not strictly necessary unless you want to use the associated subsystems.
For more information about all of the volumes that are provided by the ADCD deliverable, see the ADCD documentation that is available at this website:
4.3.2 Installing z/VM
If your target environment is to run your sysplex under z/VM (it can be a base or a Parallel Sysplex), you should install the ADCD z/VM package now.
For our Parallel Sysplex, we used the ADCD z/VM 6.3 release3. We downloaded the following volumes:
•M01RES
•630RL1
•630RL2
•M01W01
•M01S01
•M01P01
•VMCOM1
•VMCOM2
•M01W02
•M01W03
The VMPROD volume (which is part of the z/VM 6.3 ADCD package) is not strictly needed for Parallel Sysplex operation.
Ensure that you update your devmap file with the statements for the z/VM volumes. You can find a sample devmap file on the download site where you obtain the ADCD z/VM volumes. However, to save you time, we used the following statements (for simplicity, we recommend that you also use these device numbers):
device 0200 3390 3990 M01RES
device 0201 3390 3990 630RL1
device 0202 3390 3990 630RL2
device 0203 3390 3990 M01W01
device 0204 3390 3990 M01S01
device 0205 3390 3990 M01P01
device 0206 3390 3990 VMCOM1
device 0207 3390 3990 VMCOM2
device 0208 3390 3990 M01W02
device 0209 3390 3990 M01W03
device 020A 3390 3990 VMPROD
For more information about the use of and maintaining the z/VM system, see the z/VM product documentation that is available at this website:
For information about getting z/VM up and running under zPDT, see the chapter titled “Other System z Operating Systems” in IBM zPDT Guide and Reference System z Personal Development Tool, SG24-8205, which is available at this website:
To give you some advance help, we provide the following zPDT commands that you must issue to load z/VM under zPDT (you can start VM now to get some experience with it if you want, but you must shut it down again to complete some of the later steps in this process):
•LOADPARM 0700 is the command defines 3270 device 700 as the VM IPL console.
•IPL 0200 is the device number of the M01RES volume. The VMCOM1 volume should be defined on device number 0206 in your devmap file).
•On the x3270 session that corresponds to device 700, press PF10 to proceed with loading z/VM.
You do not need to be a z/VM expert to use it to host your sysplex. However, you must be familiar with the following tasks:
•Loading and shutting down z/VM under zPDT.
•Logging on and off virtual machines.
•Autologging the CF virtual machines.
•Updating the VM directory and using the DIRECTXA command to activate the updated directory.
•DIALing to a virtual 3270 device so that you can log on to z/OS applications, such as TSO or CICS.
If you are not familiar with z/VM, we recommend installing z/VM and running your ADCD z/OS system in monoplex mode under z/VM. This approach gives you an opportunity to get used the use of z/VM without the added complexity of running multiple z/OS guests. This experience is valuable later when you are ready to move to a Parallel Sysplex environment.4
4.3.3 Download and create volumes
Now that z/VM is installed and you are familiar with the mechanics of running z/OS under z/VM, the next step is to download the volumes that are provided by the 2016 Sysplex Extensions. There are also new volumes that you create and then populate with system data sets.
The zPDT 2016 Sysplex Extensions uses the following volumes:
•CF0001 : This volume is part of the zPDT 2016 Sysplex Extensions package. It contains CDSs, sample JCL, and sample definitions.
•CICS01 : This volume is also part of the zPDT 2016 Sysplex Extensions package. It contains the user catalog and data sets for the CICSplex regions.
•CICS02 : This volume is the second volume for the CICSplex data sets and also is included in the 2016 Sysplex Extensions package.
•DB2001 : This volume is part of the zPDT 2016 Sysplex Extensions package. It contains the data sets for the DB2 data sharing subsystems.
•DB2002 : This is the second volume for the DB2 data sets and also is included in the 2016 Sysplex Extensions package.
•F1PAGX : This volume starts as an empty volume so it is not downloaded as part of the package. This volume contains page data sets for the second z/OS system (S0W2).
•F1PAGY : This volume is an empty volume that will contain page data sets for the second z/OS system.
•F1PAGZ : This volume is an empty volume that will contain page data sets for the second z/OS system.
•F1SYS2 : This empty volume contains system and work data sets that are used by the second z/OS system.
•WORK01 : This volume also starts as an empty volume. It is used to contain work data sets only and is mounted as a STORAGE volume in the VATLSTPS member.
CF0001 is defined as a 3390-1, and the CICS and DB2 volumes are 3390-3s. Because you are allocating the other volumes, you control their size. We recommend 3390-9s for the paging volumes. The F1SYS2 and WORK01 volumes should be at least 3390-3s.
The CF0001, CICS01, CICS02, DB2001, and DB2002 volumes should be downloaded from the following website:
There are five .gz files, one for each of the first five volumes. Download the following files into the directory that contains your ADCD z/OS files:
•cf0001.gz
•cics01.gz
•cics02.gz
•db2001.gz
•db2002.gz
After the downloads complete, open a window, browse to the directory that contains your z/OS volumes, and use the gunzip command (for example, gunzip -c cf0001.gz > CF0001) to extract each of the .gz files.
The other volumes contain only data sets that are defined during the installation process. Therefore, you only need to create the empty volumes at this stage in the process. Some of the data sets on these volumes must be cataloged in your master catalog. Therefore, we feel that providing you with instructions and jobs to create them is easier than providing the volumes pre-populated and then having to cataloged again the VSAM data sets in your master catalog.
Use the following commands to create Linux files now that will contain the z/OS volumes later (this process can take some time, depending on the speed of your PC’s hard disk drive):
•alcckd F1PAGX -d3390-9
•alcckd F1PAGY -d3390-9
•alcckd F1PAGZ -d3390-9
•alcckd F1SYS2 -d3390-3
•alcckd WORK01 -d3390-3
You now have the five volumes that are provided by this package, and five volumes that you soon initialize by using ICKDSF. But before we can perform that initialization, we update the devmap file to add the definitions for the extra volumes.
4.3.4 Establish a known restart point
When you have a working z/OS system running under z/VM and before you start making any changes to z/VM or z/OS to add sysplex support, it is recommended that you create a clean restart point that you can fall back to if your changes result in a system that does not initialize successfully.
One way to create this restart point is to ensure that the zPDT environment (z/OS and z/VM) is stopped and then take a copy of the z/VM and z/OS Linux files. If there are problems, you can then restore those volumes (or starting zPDT by using a devmap file that references those copies).
An alternative is to use the disk versioning support that is provided by zPDT. This support is an attractive option if you expect to be performing repetitive testing and want to repeatedly return to a known restart point. For more information about this capability, see the chapter “CKD versioning” in IBM zPDT Guide and Reference System z Personal Development Tool, SG24-8205, which is available at this website:
To help you get started, we included a basic Linux script to enable versioning support for our z/OS and z/VM disks. The script is shown in “zPDT Disk versioning sample script” on page 125. You can customize this script to include more volumes (your own z/OS volumes, for example), or create a corresponding script to accept the outstanding changes and create a restart point, or to discard the changes and return to your known restart point. The z/OS and z/VM systems must be shut down at the time these scripts are run.
If you do not want to back up all of your volumes, we recommend that you create a backup of the following data sets at a minimum:
•ADCD.Z21F.PARMLIB (or the corresponding data set for your level of ADCD)
•ADCD.Z21F.PROCLIB (or the corresponding data set for your level of ADCD)
•USER.PARMLIB
•USER.PROCLIB
•USER.TCPPARMS
•USER.VTAMLST
 
Note: Your z/VM and z/OS system likely is down at this point; therefore, make a note to run this job after you bring your z/OS system back up.
Apart from providing an ability to back out any changes, having a “before” copy of the data sets that you are changing helps you to more easily visualize the differences between the system that you started with (the ADCD monoplex) and the sysplex with which you end up.
Finally, backups are like umbrellas in that you likely need a backup only if you do not have one. Therefore, taking a few minutes to create them at this point is a good investment of your time. To make it even easier, you can use the JCL that is shown in Example 4-1.
Example 4-1 Sample JCL to back up key system data sets
//BACKUP JOB CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID
//BACKUP EXEC PGM=IEBCOPY
//SYSPRINT DD SYSOUT=*
//SYSUT3 DD UNIT=SYSDA,SPACE=(3120,(20,10))
//SYSUT4 DD UNIT=SYSDA,SPACE=(3120,(20,10))
//*
//IN1 DD DISP=SHR,DSN=ADCD.Z21F.PARMLIB
//OT1 DD DISP=(NEW,CATLG),DSN=SYSPLEX.Z21F.PARMLIB.BKUP,
// UNIT=SYSDA,VOL=SER=F1SYS1,
// LIKE=ADCD.Z21F.PARMLIB
//IN2 DD DISP=SHR,DSN=ADCD.Z21F.PROCLIB
//OT2 DD DISP=(NEW,CATLG),DSN=SYSPLEX.Z21F.PROCLIB.BKUP,
// UNIT=SYSDA,VOL=SER=F1SYS1,
// LIKE=ADCD.Z21F.PROCLIB
//IN3 DD DISP=SHR,DSN=USER.PARMLIB
//OT3 DD DISP=(NEW,CATLG),DSN=SYSPLEX.USER.PARMLIB.BKUP,
// UNIT=SYSDA,VOL=SER=F1SYS1,
// LIKE=USER.PARMLIB
//IN4 DD DISP=SHR,DSN=USER.PROCLIB
//OT4 DD DISP=(NEW,CATLG),DSN=SYSPLEX.USER.PROCLIB.BKUP,
// UNIT=SYSDA,VOL=SER=F1SYS1,
// LIKE=USER.PROCLIB
//IN5      DD DISP=SHR,DSN=USER.TCPPARMS
//OT5      DD DISP=(NEW,CATLG),DSN=SYSPLEX.USER.TCPPARMS.BKUP,
// UNIT=SYSDA,VOL=SER=F1SYS1,
// LIKE=USER.TCPPARMS
//IN6      DD DISP=SHR,DSN=USER.VTAMLST
//OT6      DD DISP=(NEW,CATLG),DSN=SYSPLEX.USER.VTAMLST.BKUP,
// UNIT=SYSDA,VOL=SER=F1SYS1,
// LIKE=USER.VTAMLST
//*
//SYSIN DD *
COPY INDD=IN1,OUTDD=OT1
COPY INDD=IN2,OUTDD=OT2
COPY INDD=IN3,OUTDD=OT3
COPY INDD=IN4,OUTDD=OT4
  COPY INDD=IN5,OUTDD=OT5
  COPY INDD=IN6,OUTDD=OT6
/*
Ensure that the job ended with return code 0 before you start making changes to these data sets.
Starting over
If you find yourself in a position where you want to go back to the beginning and start the installation of the 2016 Sysplex Extensions all over again, you should delete (or rename) all of the following volumes and run the gunzip command against the downloaded data sets again:
•CF0001
•CICS01
•CICS02
•DB2001
•DB2002
Additionally, you should delete all of the following volumes and create versions by using the alcckd command:
•F1PAGX
•F1PAGY
•F1PAGZ
•F1SYS2
•WORK01
4.3.5 Updating devmap to add new volumes
Before any volume can be used by a system that is running under zPDT, the device and the associated Linux file must be defined in the devmap file. This requirement means that you must update your devmap file by adding the new volumes to your definitions.
z/VM automatically generates a device for any device that you define in the devmap file. However, on the z/OS side, you must make sure that the device numbers that you use are defined in the IODF (for more information about the devices and associated device numbers that are defined in the ADCD-provided IODF, see Table A-1 on page 122).
You can use the following devmap statements as examples to help you add the new volumes to your devmap (all of these addresses are defined as 3390 disks in the ADCD z/OS IODF file):
device 0ab0 3390 3990 CF0001
device 0ab1 3390 3990 CICS01
device 0ab2 3390 3990 CICS02
device 0ab3 3390 3990 DB2001
device 0ab4 3390 3990 DB2002
device 0ab5 3390 3990 F1PAGX
device 0ab6 3390 3990 F1PAGY
device 0ab7 3390 3990 F1PAGZ
device 0ab8 3390 3990 F1SYS2
device 0ab9 3390 3990 WORK01
The last value in each line is the Linux file name for the respective volume. If your devmap file includes a directory list in the file name (for example, ‘frank/z/F1RES1’), you must adjust the device statements accordingly.
When you are updating the devmap, note the device number that you assign to the new volumes (you can enter the information in Table 4-3). The devmap points only to a Linux file and there is not necessarily any correlation between the file name and the contents of the file. However, we strongly recommend that the name of the Linux file matches the volser of the volume that is in that file. For example, Linux file F1SYS2 should contain the z/OS volume that is called F1SYS2. Failing to use this naming convention can lead to confusion and much wasted time later on.
Table 4-3 zPDT 2016 Sysplex Extensions volumes
Volser
Linux file name
Device number
Initialized?
CF0001
 
 
N/A
CICS01
 
 
N/A
CICS02
 
 
N/A
DB2001
 
 
N/A
DB2002
 
 
N/A
F1PAGX
 
 
 
F1PAGY
 
 
 
F1PAGZ
 
 
 
F1SYS2
 
 
 
WORK01
 
 
 
Now is a good time to add some commands to the devmap file to automatically start some x3270 sessions for you. When you are running z/OS under z/VM, you often find that you need the following x3270 sessions:
•One session for the z/VM console (OPERATOR normally is logged on that session)
•One session for each z/OS system console
•Two sessions with which you can log on to TSO without requiring TCP access
•Two sessions for logging on to various z/VM virtual machines
To support these sessions, consider adding the following statements after the processors statement in the [system] section of your devmap file now:
command 2 x3270 localhost:3270
command 2 x3270 localhost:3270
command 2 x3270 localhost:3270
command 2 x3270 localhost:3270
command 2 x3270 localhost:3270
command 2 x3270 localhost:3270
command 2 x3270 localhost:3270
You also can update the devmap to add the definitions of the OSA devices to connect your systems to the network. For more information about using the statements, see 4.3.16, “Network definitions” on page 66. For now, add the following definitions:
[manager]
name awsosa 0023 --path=A0 --pathtype=OSD --tunnel_intf=y
device 400 osa osa
device 401 osa osa
device 402 osa osa
device 408 osa osa
device 409 osa osa
device 40A osa osa
 
[manager]
name awsosa 0024 --path=f0 --pathtype=OSD
device 404 osa osa
device 405 osa osa
device 406 osa osa
device 40C osa osa
device 40D osa osa
device 40E osa osa
 
Note: The device numbers and the distinction between which devices are used for a tunnel to the underlying Linux system are important. The values that are used here match the values in the default ADCD-provided VM directory. Those values in turn match the values in the IBM VTAM® and TCP parms. Unless you are experienced with VTAM and TCP, we suggest that you use these values exactly as they are provided here.
The exception is the value on the path= parameter, which must be tailored to match the value from your PC. For more information, see 4.3.16, “Network definitions” on page 66.
If your zPDT system is running, you should shut it down after you apply the changes to the devmap file. Then, run the awsstop command, followed by the awsstart command to load the new devmap information. Devices that are not defined in the devmap file cannot be added dynamically; therefore, you must stop and restart zPDT to make them known to zPDT.
When the new devmap loads successfully by using the awsstart command, the next step is to IPL z/VM. The VM IPL address is 0200 and the console address (which is specified on the loadparm) should be 0700. The console is written to quickly, but you might need to minimize some of the other x3270 windows to see the VM console.
When the system finishes the IPL process, verify that the device numbers that you assigned to your new volumes are known to the system (in z/VM, you can run the Q nnnn command where nnnn is the device number that you used in the devmap file) command from the OPERATOR ID. The volumes that were delivered by the zPDT 2016 Sysplex Extensions should be online. The output from the Q command displays something that is similar to DASD 0AB0 CF0001. The devices that contain the empty volumes (the last five volumes that are listed in Table 4-3 on page 46) are shown as ‘FREE’ until you initialize them.
4.3.6 Configuring z/VM guests
The Parallel Sysplex requires four virtual machines (also known as guests): two Coupling Facility Virtual Machines (called CFCC1 and CFCC2) and two z/OS virtual machines, called S0W1 and S0W2. If you want to run the ADCD system as a monoplex under VM, we recommend that you use a virtual machine called BASEAD. The z/VM 6.3 ADCD package includes the definitions for all these virtual machines in the supplied VM directory, which is stored in the file that is called USER DIRECT C on the MAINT user ID. The initial password for these user IDs matches the user IDs.
 
Important: The BASEAD guest should not be used at the same time as the S0W1 or S0W2 guests.
To make it easier to share the disks between multiple guests and to add guests if you need a sysplex with more than two members, all of the z/OS disks are defined as belonging to a virtual machine called MVSDUMMY. The S0W1, S0W2, and BASEAD user IDs are all defined to link to the MVSDUMMY-owned disks. (The VM directory statements that we used for these four IDs are described in “Sample z/VM Directory entries” on page 114.)
The sample definitions contain more DASD (MDISK and LINK) statements than you need for the basic ADCD systems. This configuration is used to make it easier to add volumes to your systems in the future.
You might need to make only one small change to the ADCD VM Directory. The WRKALLEG option after an MDISK statement controls how z/VM segments channel programs. If you specify WRKALLEG for a device, z/VM does not segment a channel program, which ensures that any working allegiance is not severed by z/VM ending the channel program “early.” (Anything that does atomic I/Os needs working allegiance.) In general, it should be defaulted to OFF because OFF allows z/VM to better manage channel programs from guests. However, the WRKALLEG option must be present for any volumes that contain CDSs.
Because we do not know which address you use for the CF0001 volume (the volume that contains the CDSs for the base and Parallel sysplexes), you must edit the VM directory and add the WRKALLEG statement at the appropriate location. For example, if you use the same addresses as our devmap file that was described in “Sample devmap file” on page 112, you insert a DASDOPT WRKALLEG statement after the MDISK AB0 statement.
After you make any required changes to the directory entries, run the DIRECTXA USER DIRECT C command. Running this command updates the VM directory from your source file. You must perform this update before you log on to the z/OS virtual machines.
4.3.7 Initializing new volumes
The next step is to use ICKDSF to initialize the new empty volumes by using your ADCD z/OS monoplex system.
Log on to the BASEAD user ID on z/VM. When you do, you see many ‘DASD 0Axx offline’ messages. Those messages relate to the spare devices that we referred to in 4.3.6, “Configuring z/VM guests” on page 48, so they can be ignored.
Now IPL z/OS by running the following commands:
TERM CONMODE 3270
IPL A80 LOADP 0A8200M1
Your system initially loads in monoplex mode, and uses the x3270 session in which you entered the commands as the z/OS console.
When the system comes up, issue D U,,,nnnn,1 commands to verify that the new devices (the devices that you must initialize) are offline (they should be offline because they are not yet initialized).
The next step is to logon to TSO by using IBMUSER or ADCDMST. To get to the z/OS TSO logon window, enter DIAL BASEAD in the COMMAND area of any of the available VM screens.
Your ADCD.LIB.JCL data set should contain a member that is called DSFINIT. Use the information that you entered in Table 4-3 on page 46 to help customize the job to be sure that you are using the correct device number for each volume. Ensure that you initialize only the volumes that do not have “N/A” in the Initialized column. Update the PGM=ICKDSF statement to add REGION=0M5 and tailor the SYSIN input as shown in the following example:
INIT UNIT(0AB5) NVFY VOLID(F1PAGX) VTOC(0,1,29) INDEX(2,0,15)
Perform this process for each of the five new volumes (F1PAGX, F1PAGY, F1PAGZ, F1SYS2, and WORK01). You must reply U to the ICK003D message on the z/OS console for each volume. After the initialization jobs complete (check to ensure that they ended with return code 0), run the V nnnn,ONLINE command to bring those devices online.
4.3.8 Importing user catalogs
Most of the data sets that are provided by the zPDT 2016 Sysplex Extensions are cataloged in user catalogs on the 2016 Sysplex Extensions-provided volumes. To make those user catalogs and the data sets they reference available to your system, you must run an IDCAMS IMPORT CONNECT to make them known to your master catalog.
 
Note: The 2016 Sysplex Extensions assumes that you use the same master catalog for the Parallel Sysplex, base sysplex, and your monoplex configurations. Having separate master catalogs complicates matters and provides no extra benefit.
Job IMPCONN in data set SYSPLEX.PARALLEL.CNTL on the CF0001 volume performs the IMPORT CONNECTs and defines the related aliases for you.
Run the IMPCONN job now and verify that it ends with return code 0.
4.3.9 Creating system-specific system data sets
There are several system data sets that should not be shared between systems. In this step, we allocate those data sets for the S0W2 system. We also make some changes to the S0W1 data sets to make them more amenable to a sysplex environment. Figure 4-1 shows the contents of the F1PAGA/B/C/X/Y/Z and the F1SYS1 and F1SYS2 volumes at the start of this step.
Figure 4-1 System volumes and system data sets
Figure 4-2 on page 51 shows the contents of those volumes after you complete all of the tasks in this step. You see that there are data sets for the S0W1 and S0W2 systems when running in sysplex mode, and data sets with the original names that can be used when running in monoplex mode.
Figure 4-2 System volumes and system data sets
Data set SYSPLEX.PARALLEL.CNTL (you can access it by using the normal catalog search order following the IMPCONN job) contains a job that is called VSAMS0W2 to define the Paging, VIO, SMF, and LOGREC data sets for system S0W2. The page data sets are allocated on the F1PAGX/Y/Z volumes. The other data sets are allocated on the F1SYS2 volume. All of these data sets are cataloged in the master catalog.
Submit the VSAMS0W2 job now. This job formats all of the page data sets. It might appear that nothing is occurring, but be patient. On our system, it took nearly 10 minutes and then ended with a return code 0.
Reallocating page data sets for S0W1 system
The S0W1 system (when it is part of the sysplex) could use the paging, SMF, VIO, and LOGREC data sets of the base (non-sysplex) z/OS system. However, to demonstrate the use of system symbols in system data set names, we provide a set of jobs that allocate the equivalent data sets for system S0W1.
Because the page data sets on your ADCD system take up the entire volume, the following process is used to allocate the new page data sets (this process seems long-winded, but the results are worth the effort):
 
Tip: This step and the following step (cloning the OMVS data sets) are I/O intensive. On a PC with a single hard disk drive, running multiple of these jobs in parallel elongates the overall elapsed time. Therefore, it is suggested that these steps are completed in sequence and wait for each step to complete before starting the next step.
1. Run the D ASM command. The response tells you how many local page data sets are in use; most likely, there are two sets: SYS1.LOCALA.PAGE and SYS1.LOCALB.PAGE. Make a note of those data set names.
2. If SYS1.LOCALC.PAGE was not in the list, do an ISPF 3.4 for SYS1.LOCALC.PAGE and delete that data set by entering DEL / PGSPC on the appropriate line in the data set list.
 
Note: If you cannot delete the page data set by using this method, customize and submit the DELPGSPC job in SYSPLEX.PARALLEL.CNTL to perform the delete by using a batch job.
3. If SYS1.LOCALC.PAGE was in the list, run a PAGEDEL DELETE,PAGE=SYS1.LOCALC.PAGE command. This command moves all active pages out of that data set. When the command completes (it often takes a few minutes), do a 3.4 for SYS1.LOCALC.PAGE and delete that data set (the PAGEDEL command empties only the data set, it does not delete it). You now have sufficient space on the F1PAGC volume to allocate two page data sets: one with the original ADCD name and one with a name that includes the system name.
4. Run the VSAM1A job from the SYSPLEX.PARALLEL.CNTL data set. This job allocates two local page data sets on F1PAGC: SYS1.S0W1.LOCALC.PAGE (for use by S0W1 when in sysplex mode), and SYS1.LOCALC.PAGE (for use by your monoplex system). The system formats the page data sets as part of the allocation process, so you should expect the job to run for a few minutes.
5. When the VSAM1A job completes, run a PAGEADD PAGE=SYS1.LOCALC.PAGE command to bring that page data set into service.
6. Run a PAGEDEL DELETE,PAGE=SYS1.LOCALB.PAGE command to empty the local page data set on F1PAGB. When the command completes (it often takes a few minutes and you see an IEE205I message that indicates that the page data set was “deleted”), do an ISPF 3.4 for SYS1.LOCALB.PAGE and delete that data set.
7. Run the VSAM1B job. This job allocates two local page data sets on F1PAGB: SYS1.S0W1.LOCALB.PAGE, and SYS1.LOCALB.PAGE.
8. After the VSAM1B job completes with return code 0, run a PAGEADD PAGE=SYS1.LOCALB.PAGE command to bring that page data set back into service.
9. Run a PAGEDEL DELETE,PAGE=SYS1.LOCALA.PAGE command to empty the local page data set on F1PAGA. When the command completes, do a 3.4 for SYS1.LOCALA.PAGE and delete that data set.
10. Run the VSAM1C job. This job allocates new SMF, VIO, and LOGREC data sets containing the system name for S0W1 on the F1SYS1 volume, plus two local page data sets on F1PAGA: SYS1.S0W1.LOCALA.PAGE, and SYS1.LOCALA.PAGE.
11. When the VSAM1C job completes, run the PAGEADD PAGE=SYS1.LOCALA.PAGE command to bring that page data set back into service.
This process can take up to 20 minutes (most of which is spent waiting for the jobs to finish initializing the new page data sets); however, at the end of this process, you have a set of page data sets that can be used by the standard ADCD z/OS monoplex system. you also have a set of page data sets that can be used by the base sysplex or Parallel Sysplex systems. You also have a job (VSAM1C) and a process that you can use if you want to create system-specific data sets for another system in the future.
You can use the IEASYSxx and IEASYMxx parmlib members that are provided with this package without having to modify them. Those members can be easily extended to support any number of systems if you use consistent naming for the system-specific data sets.
A bonus is that you rarely have an opportunity to remove and add page data sets to a running system, so this process gives you a chance to test and become familiar with the process if you ever need to use it on a production system.
When running in sysplex mode, you can save LOGREC and SMF data in a log stream and LOGREC and SMF data sets that are allocated by job VSAM1C are not used. However, by creating these data sets, you give yourself the option of running in DATASET or LOGSTREAM mode, and dynamically switching back and forth between the two.
4.3.10 Creating zFS file systems for system S0W2
A subset of the zFS data sets is system-specific. The 2016 Sysplex Extensions package provides a job that is called OMVSCLON in SYSPLEX.PARALLEL.CNTL to create a copy of these data sets for system S0W2 and place them on volume F1SYS2.
The naming convention of the ZFS data sets in our sample system is not ideal for a sysplex environment. Ideally, we would change the ADCD21F and BDCD21F qualifiers to reflect the names of the systems that are using the data set (S0W1 and S0W2). However, this process involved too many other changes in the base ADCD system. This is a change that might be made in a future release.
Our ADCD 2.1 system had the sysplex root and instance file systems created. If the sysplex root did not exist, SYS1.SAMPLIB(BPXISYZR) and SYS1.SAMPLIB(BPXISYZS) provide jobs to create it.
4.3.11 Creating Health Checker persistent data data set for S0W2
The z/OS Health Checker persistent data data set (called HZSPDATA) provides the Health Checker with the ability to carry information over from one IPL to the next. This capability is powerful because the Health Checker can identify changes that were introduced by the IPL of which you might otherwise be unaware.
The ADCD system includes a data set that is called ADCD.S0W1.HZSPDATA that is used by the Health Checker started task on system S0W1. In this step, we allocate a corresponding data set for the S0W2 system. If you do not run this step, Health Checker fails with a JCL error on system S0W2.
Submit the HZSALLCP job in SYSPLEX.PARALLEL.CNTL. to allocate the ADCD.S0W2.HZSPDATA data set.
4.3.12 Recataloging master catalog data sets
A few data sets (the new 2016 Sysplex Extensions-supplied CDSs) are provided on the 2016 Sysplex Extensions-supplied CF0001 volume that must be cataloged in the master catalog. Job RECATLG in SYSPLEX.PARALLEL.CNTL contains the IDCAMS statements to add those data sets to your master catalog.
The data sets that are cataloged in the master catalog all have a high-level qualifier of PARALLEL. Check to ensure that an alias of PARALLEL is not already defined in the master catalog. Then, run the RECATLG job and ensure that it completes with return code 0.
4.3.13 SMS changes
There is an increasing number of cases where software products require that data sets are placed on SMS-managed volumes. For this package, some of the DB2 data sets must be SMS-managed. For simplicity, we also packaged our entire CICSplex environment in two SMS-managed volumes (CICS01 and CICS02).
As a result, multiple changes are needed for SMS. You have an SMS SCDS and ACDS (they are provided by ADCD) and you likely made changes to them. For that reason, we did not want to ship replacement SMS control data sets because their use would regress your changes. Also, there is no mechanism to merge two sets of SMS control data sets. There is also no way to update the SMS definitions from a batch job, so we have no choice but to have you apply these changes by using ISPF.
However, the process is not as bad as it seems; it should take you only a few minutes. The following changes are required:
•The second z/OS system (S0W2) and the sysplex name (ADCDPL) must be added to the SMS configuration.
•Two data classes must be added for the automatic allocation of LOGR staging and offload data sets, and one data class is added for DB2 use.
•Two storage groups must be defined: one for the DB2 user volumes and one for the CICS user volumes.
•A new storage class must be defined for the data sets on the CICS or DB2 SMS-managed volumes.
•The SMS storage class and storage group ACS routines must be updated to reflect the new storage classes and storage groups.
•The ADCD-supplied SMS control data sets must have their share options changed to 3,3 to support cross-system sharing.
Adding S0W2 and ADCDPL to SMS
Complete the following steps:
1. Go to the ISMF panels in ISPF (option M.2 in recent ADCD systems).
2. Ensure that you are in Administrator mode.
If you can see option 8 (Control Data Set) in the panel, you are in Administrator mode.
If not, select option 0 (Profile), then option 0 (User Mode), then option 2 (Administrator). Then, exit out of ISMF (by pressing F3) and restart it.
3. Select option 8 (Control Data Set).
4. Set the CDS name to SYS1.SCDS at the top of the panel.
5. Select option 3 (Alter).
6. Page down (F8) to the second panel.
7. Specify option 1 (Add), and System Name S0W2. Then, press Enter.
8. Specify option 1 (Add), and Sys Group Name ADCDPL. Then, press Enter.
9. Exit this panel (F3).
10. Select option 4 (Validate the SCDS) and look for the message SUCCESSFUL VALIDATION in the upper right corner of the window.
11. Press F3 to exit this panel.
12. Select option 5 to activate the CDS. Enter a forward slash (/) to request activation.
You should see an ACTIVATION SCHEDULED message and the IBM MVS™ console should have a NEW CONFIGURATION ACTIVATED message.
13. Press F3 to exit from ISMF.
Creating data classes
The System Logger uses the following types of data sets for log streams:
•Staging data sets. These sets are optional, depending on how the log stream is defined. They must have a CI Size of 4KB.
•Offload data sets. Every log stream has one or more offload data sets. These data sets support any CI Size that is a multiple of 4KB; however, it is highly recommended that they have a CI Size of 24 KB for optimal performance.
Because of the different CI Sizes, two data classes are necessary for System Logger use: one for the staging data sets (named LOGR4K) and one for the offload data sets (named LOGR24K).
To define the LOGR4K data class, complete the following steps:
1. Go to the ISMF panels in ISPF.
2. Select option 4 (Data Class).
3. Set CDS name to SYS1.SCDS at the top of the panel.
4. Enter LOGR4K as the Data Class Name.
5. Select option 3 (Define) and press Enter.
6. Press F8 to scroll through several panels. Make only the following changes:
 – Description = Data class for Logger staging data sets (Page 1)
 – RECORG = LS (Page 4)
 – CIsize Data = 4096 (Page 4)
 – Shareoptions Xregion = 3 (Page 6)
 – Xsystem = 3 (Page 6)
7. Press F3 to return to the main ISMF menu.
8. Repeat these steps for the LOGR24K data class, remembering to specify a CISIZE of 24576 instead of 4096.
Also, DB2 now requires that some of its data sets are on SMS-managed volumes. For more information about this requirement, see this website:
To define the data class for DB2, complete the following steps:
1. Enter DPDGDC as the Data Class Name.
2. Select option 3 (Define).
3. Press F8 to scroll through a number of panels. Make only the following changes:
 – Description = Data class for DB2 (Page 1)
 – Data Set Name Type = EXT (Page 2)
 – If Ext = R (Page 2)
 – Extended Addressability = Y (Page 2)
 – Record Access Bias = U (Page 2)
4. Press Enter to save your changes and then, press F3 to return to the main ISMF menu.
5. Exit to the ISMF Primary Option Menu.
6. Select option 8 (Control Data Set) and option 5 (Activate the CDS) to activate the modified CDS.
Defining new storage groups
Complete the following steps to define the two new storage groups:
1. Go to the ISMF panels in ISPF.
2. Select option 6 (Storage Group).
3. Set CDS name to SYS1.SCDS at the top of the panel.
4. Enter CICFILES as the Storage Group Name.
5. Enter POOL as the Storage Group Type
6. Select option 3 (Define) and press Enter.
7. Change Auto Migrate and Auto Backup to N and press Enter.
8. Press F3 to save your changes.
9. Select option 5 (Volume) to define your CICS volumes.
10. Enter 2 (Define). Then, tab down to the section where you specify the volsers of the volumes that are in this storage group.
11. Enter CICS0 in the Prefix column, 1 in the From column, and 2 in the To column
12. Press Enter.
13. Press F3 to save your changes. Then, press F3 again to return to the first Storage Group panel.
14. Repeat these steps for the DB2FILES storage group, using volsers of DB2001 and DB2002.
15. Exit to the ISMF Primary Option menu.
16. Select option 8 (Control Data Set) and option 5 (Activate the CDS) to activate the modified CDS.
Defining new storage classes
To be on a storage group volume, a data set must be SMS-managed. To be SMS-managed, the data set must have a storage class. Complete the following steps to define a simple storage class that is used for all data sets in the CICS or DB2 storage groups:
1. Go to the ISMF panels in ISPF.
2. Select option 5 (Storage Class).
3. Set CDS name to SYS1.SCDS at the top of the panel.
4. Enter PSADDON as the Storage Class Name.
5. Select option 3 (Define) and press Enter.
6. You do not need to change any of the settings. Press F3 to save the definition of the new storage class.
7. Press F3 to save your changes.
8. Select option 8 (Control Data Set) and option 5 (Activate the CDS) to activate the modified CDS.
Updating ACS routines
The ADCD-provided SMS ACS routines are kept in data set SYS1.SMS.CNTL. The following sources are used for the active ACS routines:
•Data class : ACSSTORD
•Storage class: DB2STORC
•Storage group : DB2STORG
You can always find the location of the source of the currently active ACS routines by selecting option 7 (Automatic Class Selection) from the ISMF Primary Option menu, and then selecting option 5 (Display). You see a list of routines and their location, as shown in Figure 4-3.
Figure 4-3 ISMF Display of ACS routines information
The data class ACS routine must be updated for the new DB2 subsystems that are provided with this package. Make the following changes:
1. Save a copy of the current data class member (ACSSTORD in this case).
2. Add the following lines near the end of the member:
IF &DSN(1) = 'DSNDPDG' THEN
DO
IF &DSN(2) = 'DSNDBC' THEN
DO
IF &DSN(3) = 'DSNDB01' THEN
DO
SET &DATACLAS='DPDGDC'
END
IF &DSN(3) = 'DSNDB06' THEN
DO
SET &DATACLAS='DPDGDC'
END
END
IF &DSN(2) = 'DSNDBD' THEN
DO
IF &DSN(3) = 'DSNDB01' THEN
DO
SET &DATACLAS='DPDGDC'
END
IF &DSN(3) = 'DSNDB06' THEN
DO
SET &DATACLAS='DPDGDC'
END
END
END
END
 
These statements are provided in the ACSDB2DC member of SYSPLEX.PARALLEL.CNTL, so you can copy them from the member to save you from creating them manually. However, that member does not contain a full replacement for the data class ACS routine. Instead, it contains only the additions that are related to the 2016 Sysplex Extensions.
We found in our testing that the END statements in the provided ACSSTORD member are sometimes incorrect. We recommend reviewing the member after you add the DB2 data class statements to ensure that every DO statement has a corresponding END statement. For example, the ACSSTORD member of SYSPLEX.PARALLEL.CNTL contains the corrected member that we used for our testing.
3. Press F3 to save your changes.
The storage class ACS routine (DB2STORC) should be edited and the following changes made:
1. Save a copy of the current storage class member (DB2STORC in this case).
2. Add the following lines to the FILTLIST section at the top of the member:
FILTLIST DB2USER             INCLUDE('DSNDPDG')
FILTLIST DB2UCAT             INCLUDE(‘UCAT.DB2USER’)
FILTLIST CICSUCAT INCLUDE('UCAT.CICSUSER')
FILTLIST CICSUSER            INCLUDE(‘CTSLOGR’, ‘CTS52’)
3. Add the following lines after the SELECT line:
WHEN (&DSN = &CICSUCAT)
DO
SET &STORCLAS = 'PSADDON'
EXIT
END
WHEN (&HLQ = &CICSUSER)
DO
SET &STORCLAS = 'PSADDON'
EXIT
END
WHEN (&HLQ = &DB2USER)
DO
SET &STORCLAS = 'PSADDON'
EXIT
END
WHEN (&DSN = &DB2UCAT)
DO
SET &STORCLAS = 'PSADDON'
EXIT
END
 
These statements are also provided in the ACSDB2SC member of SYSPLEX.PARALLEL.CNTL. That member contains only the extra statements for the storage class ACS routine; it is not a complete replacement for the entire member.
4. Press F3 to save your changes.
Finally, the storage group ACS routine must be edited and the following changes made:
1. Save a copy of the current member (DB2STORG in this case).
2. Add the following lines to the FILTLIST section at the top of the member:
FILTLIST DB2USER INCLUDE('DSNDPDG')
FILTLIST DB2UCAT INCLUDE('UCAT.DB2USER')
FILTLIST CICSUCAT INCLUDE('UCAT.CICSUSER')
FILTLIST CICSUSER            INCLUDE(‘CTSLOGR’, ‘CTS52’)
3. Add the following lines after the SELECT line:
WHEN (&DSN = &CICSUCAT)
DO
SET &STORGRP = 'CICFILES'
EXIT
END
WHEN (&HLQ = &CICSUSER)
DO
SET &STORGRP = 'CICFILES'
EXIT
END
WHEN (&DSN = &DB2UCAT)
DO
SET &STORGRP = 'DB2FILES'
EXIT
END
WHEN (&HLQ = &DB2USER)
DO
SET &STORGRP = 'DB2FILES'
EXIT
These statements are also provided in the ACSDB2SG member of SYSPLEX.PARALLEL.CNTL. That member contains only the extra statements for the storage group ACS routine; it is not a complete replacement for the entire member.
4. Press F3 to save your changes.
Having updated the ACS routines, we are now ready to translate them and then activate the new routines. Complete the following steps:
1. Go to the ISMF panels in ISPF.
2. Select option 7 (Automatic Class Selection).
3. Set CDS name to SYS1.SCDS.
4. Select option 2 (Translate) and press Enter.
5. On the ACS Source Data Set line, add SYS1.SMS.CNTL.
6. On the ACS Source Member line, enter the name of your updated data class member.
7. On the Listing Data Set line, enter a valid data set name (it is created if it does not exist).
8. Press Enter.
9. Scroll to the end of the listing to ensure that the translation process ended with return code 0000.
10. Repeat these steps for the other ACS members that you updated.
11. Press F3 to return to the primary ISMF menu.
12. Select option 8 (Control Data Set) and option 5 (Activate the CDS) to activate the modified CDS.
Altering share options of SMS control data sets
Next, submit job ACDS5 in SYSPLEX.PARALLEL.CNTL to change the share options of several SMS data sets to allow them to be shared by the S0W1 and S0W2 systems. Sample JCL statements are shown in Example 4-2.
Example 4-2 Sample JCL statements
//ACDS5 JOB 1,OGDEN,MSGCLASS=X
// EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
ALTER SYS1.ACDS.DATA SHAREOPTIONS(3 3)
ALTER SYS1.SCDS.DATA SHAREOPTIONS(3 3)
ALTER SYS1.COMMDS.DATA SHAREOPTIONS(3 3)
/*
 
The SMS-related changes are now complete.
4.3.14 JES2 MAS configuration
 
Important: The installation of the 2016 Sysplex Extensions makes only two changes that could affect your current ADCD system. The change that is described in this section is one of those changes. Therefore, you must be careful that the change we recommend does not conflict with any customization that you might performed on your JES2PARM member.
JES2 must be changed to a Multi-Access Spool (MAS) configuration with two members. This change does not affect the usability of the JES2 parameters for “normal” ADCD use.
We made the following change to member JES2PARM in the ADCD PARMLIB data set. Although we attempt to avoid making any changes to the ADCD data sets, making the changes in the USER data set resulted in several other changes in this case, which increased the complexity with little benefit in return.
Also, the change that we make is consistent with running the system in monoplex mode, which means that you can switch back and forth between monoplex and sysplex mode without making any JES-related changes.
 
Tip: Because you are changing a member that is used by your running system, ensure that you can create a backup of the member before it is changed.
The whole JES2PARM member is not shown here, only the changed lines that are related to the MAS definition are shown. (We also changed the number and classes of started initiators, but this change is optional.) There already is a MASDEF statement in the JES2PARM member, so you must scroll down to find that statement, delete it, and then insert the following statements:
/* *--------------------------------------*
* Multi-Access Spool *
*--------------------------------------*
*/
MASDEF SHARED=CHECK,
RESTART=YES,
         CKPTLOCK=ACTION,
DORMANCY=(25,300),
HOLD=10,
LOCKOUT=500
 
MEMBER(1) NAME=S0W1
MEMBER(2) NAME=S0W2
These statements are included in member JES2MASD in SYSPLEX.PARALLEL.CNTL if you want to copy them from there to the end of the JES2PARM member.
The first time you bring up JES2 after making this change, you see message HASP870, which prompts you to confirm that you want to add member S0W2 to the JES2 MAS. Reply Y to this write to operator with reply (WTOR).
JES2 Dynamic Proclib
While updating the JES2PARM, we implemented JES2 dynamic proclib support. This support consists of adding the JES2 proclib definitions to the JES2PARM member. The following statements are used:
/*********************************************************************/
/* */
/* Dynamic JES2 proclib definitions */
/* */
/***************** ***************************************************/
PROCLIB(PROC00) DD(1)=(DSN=USER.PROCLIB),
DD(2)=(DSN=ADCD.&SYSVER..PROCLIB),
DD(3)=(DSN=CEE.SCEEPROC),
DD(4)=(DSN=CSQ800.SCSQPROC),
DD(5)=(DSN=IOE.SIOEPROC),
DD(6)=(DSN=EOY.SEOYPROC),
DD(7)=(DSN=HLA.SASMSAM1),
DD(8)=(DSN=CBC.SCCNPRC),
DD(9)=(DSN=SYS1.PROCLIB)
These statements are included in member JES2PRCL in SYSPLEX.PARALLEL.CNTL if you want to copy them from there.
To confirm that your changes are successful, shut down and restart JES2 without removing the proclib definitions from the JES2 JCL. When you are satisfied that your change was successful (use the $D PROCLIB command), you can remove the PROC00 DD statements from the JES2 PROC.
The use of this capability includes the following advantages:
•Simplified JES2 PROC JCL because all the DD statements for your procedure libraries can be removed from the JES2 JCL.
•The proclib concatenation can be changed dynamically, with no need to stop and restart JES2.
•If you have a syntax error in your JES2 proc JCL, JES2 does not start. However, if you have a syntax error in the PROCLIB definitions in the JES2PARM member, you are presented with an HASP469 message, which gives you the option of correcting or bypassing the invalid statement.
If a proclib concatenation (PROC00, for example) is specified in the JES2 JCL and JES2 parm member, the parm definitions are used rather than those definitions in the JCL. Therefore, you can add the statements to your JES2PARM member without removing them from the JCL. For more information about dynamically changing your proclib concatenations, see the section “Using dynamic PROCLIB allocation” in z/OS JES2 Initialization and Tuning Guide, SA32-0991.
4.3.15 Creating PARMLIB members
Many of the attributes of how your system and sysplex work are controlled via parmlib members. When this deliverable was designed, we wanted to make the installation as simple and automated as possible. In particular for the parmlib member changes, we wanted to minimize your manual intervention and avoid situations in which we provide a parameter change that clashes with values that were used for your system. We also tried to optimize the use of system symbols to minimize the number of members and the administrative effort to keep multiple duplicate or near-duplicate members in sync.
Many (but not all) parmlib members support the ability to concatenate members. If you use concatenated members, the values that are obtained from the first member of the concatenation are overridden if the same parameter is encountered in a later member. For example, assume that you specify SYSPARM(00,PS) in your IEASYMxx member. That specification indicates that IEASYS00 is read first, followed by IEASYSPS. If any parameter is specified in both members, the value from IEASYSPS is used. Any parameters that are not specified in IEASYSPS use the value from IEASYS00.
This capability allows us, where possible, to provide parmlib members that contain only the parameters that must be overridden for the sysplex environment. We use a suffix of PS (for Parallel Sysplex), BS (for base sysplex under z/VM), or ST (for base sysplex spread across two PCs) our members. The members that we provided and the changes that are in each member are listed in Table 4-4 on page 63.
Table 4-4 Parmlib members supplied by zPDT 2016 Sysplex Extensions
Member
Supports concatenation?
Changed parms
CLOCKPS
CLOCKST
Yes
Added SIMETRID value.
Changed STPMODE to YES.
COMMNDPS
Yes
Changed VTAM start command to specify that ATCSTRPS should be used rather than ATCSTR00.
 
Changed VTAMAPPL started task name to VTAMPS.
CONSOLPS
No
Replaced entire member.
Changes are to NAME parm on console definition and to enable OPERLOG.
COUPLEPS
No
Replaced entire member. Nearly all parameters changed.
DEVSUPPS
Yes
Added extended TIOT support for non-VSAM data sets.
GRSRNLPS
Yes
Convert all reserves to ENQs.
IEASYMPS
IEASYMBS
IEASYMST
Yes
Replaced entire member.
 
Adds IEASYSBS and IEASYSST sysparms.
IEASYSPS
 
 
 
IEASYSBS
 
IEASYSST
Yes
Updated to point at the members that require changes for the sysplex environment.
 
Changed GRS to TRYJOIN.
 
Changed CLOCK to enable STP.
IEFSSNPS
Yes
Added definitions for our CICSplex and data sharing DB2 subsystems.
LOADPS
LOADBS
LOADST
No
Set appropriate IEASYM parameter.
LPALSTPS
Yes
Add CICS 5.2 to LPALST.
PROGPS
Yes
Added SDSNEXIT library.
SHUTS0Wn
No
Add system-specific system shutdown commands for VTAMAPPL.
SMFPRMPS
SMFPRMBS
No
Updated the SMF data set names
System-specific log stream names.
VATLSTPS
Yes
Added work volume definition.
VTAMPS
VTAMBS
No
Tailored VTAM00 for sysplex.
Similar to VTAM00 except in how RRS is started.
To copy our parmlib members to the SYS1.IPLPARM and USER.PARMLIB data sets, submit job COPYPARM in SYSPLEX.PARALLEL.CNTL.
All of the parmlib members that are described in this section are provided as part of this package and do not require changes unless you must adjust to fit something that is specific to your configuration.
For more information about the specific changes we made to the parmlib members, see the next sections. Otherwise, see 4.3.16, “Network definitions” on page 66.
LOADPS member
This member is copied to the SYS1.IPLPARM data set rather than USER.PARMLIB. However, we include it here because it is logically related to the members of the USER.PARMLIB data set.
We wanted to consolidate to a single IEASYMxx member that can be used by multiple systems when running in a Parallel Sysplex. We also wanted the ability to control the IEASYSxx concatenation at the system level without having to have system-specific LOADxx members. Therefore, we used the LOAD00 member as a base and changed the IEASYM parameter to point at IEASYMPS.
The LOADBS and LOADST and all the other base sysplex-related members are described in 4.5.2, “Changes in parmlib” on page 77 and 4.6.4, “Required parmlib changes” on page 83.
 
Important: If you use a member other than LOAD00 when you load your ADCD system, you must update the supplied LOADPS member to reflect the changes that you made to LOAD00.
IEASYMPS member
The original IEASYM00 member was designed for a single system environment. We wanted the ability to use a single IEASYMxx member for multiple systems, so we created a IEASYMPS member. Any symbols that are common to all members of the sysplex are at the top of the member in the common area. We then added filter statements that use the VM user ID that is associated with the z/OS system to set some system-specific symbols. There is one section for user ID S0W1, and one for S0W2. If you want to add systems later, you add sections that are based on these examples. For more information about our IEASYMPS member, see “Sample IEASYMxx member for sysplex” on page 122.
IEASYSPS member
There are a few parmlib members that must be changed for the sysplex environment. Therefore, we created an IEASYSPS member that is concatenated to the standard IEASYS00 member. The IEASYSPS member contains only the parameters that we needed to override for the sysplex environment.
In addition to pointing at the other changed members, the IEASYSPS member performs the following tasks:
•Overrides the page data set names to point at system-specific data sets that were created in 4.3.9, “Creating system-specific system data sets” on page 50.
•Overrides the LOGREC parameter to point at the system-specific LOGREC data set.
•Overrides the VIO parameter to point at the system-specific STGINDEX data set.
•Overrides the GRS parameter to specify that GRS is used. The standard single-system ADCD environment specifies GRS=NONE because there is no other system with which it can share.
CLOCKPS member
One of the requirements for systems in a sysplex is that they have a common time source. z/VM provides this capability, but the CLOCKxx member must be updated to inform z/OS of the ID of the simulated external time source. This feature required a new parameter, SIMETRID, to be added. No changes were made to the ADCD-provided CLOCKxx member.
COMMNDPS member
The ADCD-provided COMMNDxx members start VTAM by using the ATCSTR00 member of USER.VTAMLST. We did not want to change that member (our objective is to make it easy to switch back to monoplex mode); therefore, we set up a new ATCSTRPS member. However, that change required a change to the S VTAM command to point at that member instead.
If we created a COMMNDPS member that contains only the S VTAM command and concatenated it to the COMMNDWS member, the S VTAM command is issued twice, once from the COMMNDWS member and again from the COMMNDPS member. Therefore, we copied the contents of COMMNDWS into COMMNDPS and changed only the S VTAM command and point at the ATCSTRPS member in VTAMLST.
CONSOLPS member
One of the requirements of being in a sysplex is that every console must have a name that is unique within the sysplex. The ADCD-supplied CONSOL00 member uses a fixed name for its consoles: L700 and C908. If two systems are loaded with the CONSOL00 member, you have two consoles that are named L700 in the sysplex, which is not permitted.
Therefore, we copied the contents of CONSOL00 into CONSOLPS and changed the NAME keyword on the console definition to “&SYSNAME.L700”. So, on system S0W1, the console is named S0W1L700 and on system S0W2, its console is named S0W2L700.
We also enabled OPERLOG by adding the OPERLOG keyword to the HARDCOPY DEVNUM parameter. We also added the HOLDMODE(YES) parameter to the DEFAULT statement, which allows you to hold the flow of messages on the console by pressing Enter. We felt that this change is useful if you are trying to debug errors during the early phases of an IPL before you can to logon to TSO to review the syslog. To restart the flow of messages, press Enter again.
COUPLEPS member
Because we are using unique CDSs for the sysplex environment, we needed a new COUPLExx member. We also took this opportunity to create a more robust XCF signaling infrastructure, so there are more transport classes and more signaling paths than in previous releases.
We also added definitions for the full set of CDSs (ARM, BPXMCDS, CFRM, LOGR, SFM, Sysplex, and WLM). We also included definitions for CTC connections between the systems. These connections are primarily intended for a base sysplex environment, where CF structures are not available. However, you can use the CTCs and the signaling structures in a Parallel Sysplex.
DEVSUPPS member
We added a new DEVSUPPS member with a single statement to enable the use of extended TIOTs for non-VSAM data sets. This addition is in line with IBM’s best practice recommendations and eliminates an exception in the z/OS Health Checker.
GRSRNLPS member
Because all z/OS systems that are sharing your zPDT z/OS volumes are in the same sysplex, it is better to use GRS than RESERVE/RELEASE to protect the integrity of those volumes. To avoid problems with RESERVEs locking out volumes, we updated the GRS Resource Names List to indicate that all RESERVEs must be converted to ENQs.
LPALSTPS member
Because we restored only the volume for one release of CICS (CICS TS 5.2), we created an LPALSTPS member to add only the LPA data set for that one release of CICS.
PROGPS member
The load library that contains the DB2 subsystem parameters (SDSNEXIT) must be APF-authorized, so we created a PROG member with only that one entry and concatenated it to the ADCD-provided PROG members.
SHUTS0W1 and SHUTS0W2 members
To make it easier to stop the system, we created system-specific versions of the SHUTALL member that is provided by ADCD. To shut down a system, run the S SHUTSYS command on the console of the system you want to shut down.
SMFPRMPS member
Unfortunately, the SMFPRMxx member does not support concatenation. Therefore, we copied the SMFPRM00 member, updated the SMF data set names, and added the SID (system ID) parameter.
VATLSTPS member
Rather than update the ADCD-provided VATLST member, we created a member that contains one entry (for the WORK01 volume) and concatenated that to the ADCD-provided VATLST00 member.
VTAMPS member
This member is used by the VTAMAPPL program to start selected address spaces after the IPL completes. The VTAMPS member is based on the ADCD-provided VTAM00 member, with the exception that it uses the &SYSNAME. system symbol where appropriate to tailor commands to the system on which they run.
4.3.16 Network definitions
Before we describe PROCLIB, TCP, and VTAM changes, we describe our network setup and the relationships between the definitions.
Our configuration featured a single network adapter on our PC. Linux and the two z/OS guests use it to communicate to the outside world. For simplicity, we do not have TCP set up on z/VM. Therefore, our configuration is similar to the configuration that is described in the chapter that is titled, “Multiple guests in one instance” in IBM zPDT Guide and Reference System z Personal Development Tool, SG24-8205, which is available at this website:
We use VNC to log on to the Linux desktop remotely (we can use this VNC to logon to VM from a remote window if necessary). As a result, we have not found the absence of TCP on z/VM to be a problem.
The various definitions feature the following relationships:
•The devmap file contains the definition for the OSA addresses and points the control units at the respective actual adapters (one for the tunnel to Linux and one for the connection to the outside world). For more information, see the sample devmap file that is shown in Example A-1 on page 112.
•The VM directory entries for each z/OS guest contain DEDICATE statements for three OSA addresses for each connection (three each for the tunnel and real network adapter). The addresses that are used for each system must be unique. Each system must have access to two sets of three consecutive OSA devices, and the first device number must be an even number. The device numbers must match those numbers that are specified in the devmap file. For more information, see the sample directory entries for S0W1 and S0W2 that are shown in Example A-4 on page 117 and Example A-5 on page 119.
•The VTAMLST data set contains one TRLE member for each system. Each member contains two TRLE definitions: one for the tunnel to Linux and one for the real network adapter. Each definition includes a portname.
•The TCPPARMS data set contains the TCP PROFILE members (one per z/OS). The DEVICE and LINK statements use the portnames that were defined for the OSA in the TRLE definitions in VTAMLST.
 
Tip: For this configuration to work, all of the systems that share a specific network adapter MUST use the same port name.
•To keep our VTAMLST simple, we use a system symbol for the name of the member that contains the OSA definitions. The value of the symbol is set in the IEASYMxx member and depends on the system. This configuration allows us to have a single ATCCONPS member that can be used by all the systems in the sysplex.
The OSA section of our devmap file resembles the following example:
[manager]
name awsosa 0023 --path=A0 --pathtype=OSD --tunnel_intf=y
device 400 osa osa
device 401 osa osa
device 402 osa osa
device 408 osa osa
device 409 osa osa
device 40A osa osa
 
[manager]
name awsosa 0024 --path=f2 --pathtype=OSD
device 404 osa osa
device 405 osa osa
device 406 osa osa
device 40C osa osa
device 40D osa osa
device 40E osa osa
To get the value of the path parameter on the name awsosa statement, run the find_io command. The output from the command on our PC resembles the following example:
 
Interface Current MAC IPv4 IPv6
Path Name State Address Address Address
------ ---------------- ---------------- ----------------- ----------------
  F2    enp13s0 UP, RUNNING 00:14:5e:57:c5:6a 192.168.1.99 *
  F1    enp24s0         UP, NOT-RUNNING 00:14:5e:57:c5:6c * * .
A0 tap0 DOWN 02:a0:a0:a0:a0:a0 * *
A1 tap1 DOWN 02:a1:a1:a1:a1:a1 * *
A2 tap2 DOWN 02:a2:a2:a2:a2:a2 * *
A3 tap3 DOWN 02:a3:a3:a3:a3:a3 * *
A4 tap4 DOWN 02:a4:a4:a4:a4:a4 * *
A5 tap5 DOWN 02:a5:a5:a5:a5:a5 * *
A6 tap6 DOWN 02:a6:a6:a6:a6:a6 * *
A7 tap7 DOWN 02:a7:a7:a7:a7:a7 * *
End of FIND_IO
In this example, you can see that path F2 is the path that includes a status of UP, RUNNING; therefore, F2 is specified on the path= statement in the devmap.
The VM directory entry for S0W1 contains the following statements:
DEDICATE 0400 0400
DEDICATE 0401 0401
DEDICATE 0402 0402
DEDICATE 0404 0404
DEDICATE 0405 0405
DEDICATE 0406 0406
The directory entry for S0W2 contains the following statements:
DEDICATE 0408 0408
DEDICATE 0409 0409
DEDICATE 040A 040A
DEDICATE 040C 040C
DEDICATE 040D 040D
DEDICATE 040E 040E
The VTAMLST TRLE definition for S0W1 contains the following statements:
OSATRL1 VBUILD TYPE=TRL
OSATRL1E TRLE LNCTL=MPC,READ=(0400),WRITE=(0401),DATAPATH=(0402), X
PORTNAME=PORTA, X
MPCLEVEL=QDIO
OSATRL2E TRLE LNCTL=MPC,READ=(0404),WRITE=(0405),DATAPATH=(0406), X
PORTNAME=PORTB, X
MPCLEVEL=QDIO
You can see that the device numbers from the VM directory entry are used for each entry; for example, 400 (READ), 401 (WRITE), and 402 (DATAPATH). The portname for that TRLE is PORTA. In this example, devices 400 - 402 are used for the tunnel to Linux. Devices 404 - 406 are used for the real network interface.
The TCP Profile member for S0W1 contains the following statements:
DEVICE PORTA MPCIPA
LINK ETH1 IPAQENET PORTA
HOME 10.1.1.2 ETH1
;
DEVICE PORTB MPCIPA
LINK ETH2 IPAQENET PORTB
HOME 192.168.1.81 ETH2
You can see that the same portname (for example, PORTA) that was specified on the TRLE definition is used on the DEVICE and LINK statements.
The TRLE definition for S0W2 contains the following statements:
OSATRL2 VBUILD TYPE=TRL
OSATRL2E TRLE LNCTL=MPC,READ=(0408),WRITE=(0409),DATAPATH=(040A), X
PORTNAME=PORTA, X
MPCLEVEL=QDIO
OSATRL3E TRLE LNCTL=MPC,READ=(040C),WRITE=(040D),DATAPATH=(040E), X
PORTNAME=PORTB, X
MPCLEVEL=QDIO
You see that although S0W2 uses different device numbers, the portnames are the same as the definition for S0W1. The Profile member for S0W2 contains the following statements:
DEVICE PORTA MPCIPA
LINK ETH1 IPAQENET PORTA
HOME 10.1.1.3 ETH1
;
; This second device is optional
DEVICE PORTB MPCIPA
LINK ETH2 IPAQENET PORTB
HOME 192.168.1.91 ETH2
If you use different portnames on the two systems, the adapter does not activate on the second system. To our knowledge, this information is not documented elsewhere.
4.3.17 Creating PROCLIB members
A few changes are required to PROCLIB members for the base system. There are many new procs for the 2016 Sysplex Extensions-provided CICS regions and DB2 subsystems; however, those changes are described in Chapter 6, “Sample CICSplex” on page 103, and Chapter 5, “Sample DB2 data sharing environment” on page 95. All changes and additions are made in the USER.PROCLIB data sets.
Run the COPYPROC job in SYSPLEX.PARALLEL.CNTL now to copy the procs. For more information about the changes that we made, continue reading this section. Otherwise, you can skip to 4.3.18, “Creating TCPPARMS” on page 70.
VTAMAPPL started tasks
VTAMAPPL is a basic automation tool that can be used to issue system commands and insert pauses when the commands are issued. The supplied VTAMAPPL proc provides the ability to override the member name, but not the data set name. We created a VTAMPS member in USER.PROCLIB because the ADCD-supplied VTAM00 member points at ADCD.Z21F.PARMLIB and we did not want to place any of our members in that data set. VTAMPS is started by using a command, such as - S VTAMPS,M=&VTAMAPPL, where &VTAMAPPL is a system symbol that indicates which VTAMAPPL member of USER.PARMLIB is used.
The SHUTSYS proc also uses VTAMAPPL to shut down started tasks in an orderly and phased manner. The SHUTSYS proc uses the &SYSNAME. system symbol to select the correct SHUTxxxx parmlib member for that system.
The VTAMPS and the SHUTSYS procs are generic and can be used to start or stop either system.
TCP/IP procedure
The ADCD-supplied TCP/IP procedure references the ADCD TCPPARMS data set, so we created a TCP/IP proc in USER.PROCLIB to point to the USER.TCPPARMS data set. This change also affects the non-sysplex AD system. The same PROFILE and DATA members are used by system S0W1, regardless of whether it is in monoplex or sysplex mode.
 
Note: The TCPIP member that is provided (and copied into your USER.PROCLIB data set) by the 2016 Sysplex Extensions is set up to use PROFILE and TCPDATA members with names that match the system name (S0W1P and S0W1D). The ADCD-provided members use a different naming convention (PROFILE and TCPDATA) because they were not intended for a sysplex environment.
4.3.18 Creating TCPPARMS
 
Important: We mentioned in 4.3.14, “JES2 MAS configuration” on page 60 that there are two steps in the implementation of the 2016 Sysplex Extensions in which you must make changes that might affect your current, running ADCD system. This step is the second of those instances.
Because network implementations can vary greatly from one system to another, it is not possible to provide a set of definitions that work in every system. This step copies the members that we used to get our systems to work in a sysplex configuration. However, it should be treated as an example; you likely must make adjustments that are based on your specific network setup.
If there is an error in your TCP definitions, you can still log on to the system by using one of the local z/VM windows and fix the problem from there.
The COPYTCPP job in SYSPLEX.PARALLEL.CNTL copies four members to your USER.TCPPARMS data set. You likely must adjust these parameters to match your LAN configuration. If you change the member names, make corresponding changes to the TCP/IP JCL in USER.PROCLIB.
The following examples show the TCP/IP DATA members for the two systems. If you connect your z/OS systems to an external network, the DOMAINORIGIN values in these members must be changed. If you intend to use a name server, the NSINTERADDR values must be provided.
Example 1: MEMBER S0W1D
The S0W1D member is used by base and Parallel Sysplex systems, as shown in the following example:
TCPIPJOBNAME TCPIP
S0W1: HOSTNAME S0W1
DOMAINORIGIN XXX.YYY.COM
DATASETPREFIX TCPIP
;NSINTERADDR xx.xx.xx.xx
RESOLVEVIA UDP
RESOLVERTIMEOUT 10
RESOLVERUDPRETRIES 1
ALWAYSWTO NO
Example 2: MEMBER S0W2D
The S0W2D member is used by base and Parallel sysplex systems, as shown in the following example:
TCPIPJOBNAME TCPIP
S0W2: HOSTNAME S0W2
DOMAINORIGIN XXX.YYY.COM
DATASETPREFIX TCPIP
;NSINTERADDR xx.xx.xx.xx
RESOLVEVIA UDP
RESOLVERTIMEOUT 10
RESOLVERUDPRETRIES 1
ALWAYSWTO NO
4.3.19 Creating VTAMLST members
We added several members to USER.VTAMLST. We provide sample VTAMLST members in SYSPLEX.VTAMLST. You can use job COPYVTAM in SYSPLEX.PARALLEL.CNTL to copy the sample members to USER.VTAMLST. We updated the ATCSTRPS, ATCCONPS, and OSATRLx members. You might need to customize these members, depending on which VTAM applications you want to automatically activate at VTAM startup, and on the device numbers that you used for your virtual OSA adapters.
 
Tip: If you change the VTAMLST members, the X symbols on the right side of some lines are continuation characters and must be in column 72 of the statement.
The naming convention (the two-letter suffix) is not carried into the TRL names.
We also added members for CICS and DB2. Those changes are described in Chapter 6, “Sample CICSplex” on page 103, and Chapter 5, “Sample DB2 data sharing environment” on page 95.
4.3.20 Customization for Parallel Sysplex complete
You now completed all of the changes that are required to start the systems in Parallel Sysplex mode. If this configuration is your target, proceed to 4.4, “Bringing up your Parallel Sysplex” on page 72. If your objective is to have a base sysplex under z/VM, there are some extra steps that must be completed. For more information about those steps, see 4.5, “Other steps for base sysplex under z/VM” on page 76. If your target environment is a base sysplex spread over two PCs, see 4.6, “Implementing a base sysplex without z/VM” on page 79.
4.4 Bringing up your Parallel Sysplex
At this point, you made all of the changes that are required to start the Parallel Sysplex.
However, to verify that you still can fall back to monoplex mode, we recommend that you shut down and then reload the z/OS system that is running under the BASEAD user ID. It should be possible to load your system in the same way as you did previously; that is, by using the same IPL address and load parm.
Having verified that your current system still initializes successfully, the next step is to start your Parallel Sysplex. This process includes the following steps:
1. Shut down the BASEAD system and log off that virtual machine.
2. Run the following commands from the OPERATOR or MAINT user IDs to initialize the two Coupling Facility Virtual Machines:
XAUTOLOG CFCC1
XAUTOLOG CFCC2
If you want to see the messages that are issued by the CFs, log on to CFCONSOL. The messages from both CFVMs are directed to that user ID.
Wait a couple of minutes to give the CFs a chance to initialize.
3. Log on to the S0W1 virtual machine. Check that you see messages, such as “HCPMFC2804I Message devices 1400-1403 defined and coupled to CFCC1.” for each of the two CFs. These messages confirm that the CFVMs finished initializing. If you do not see these messages, log off and wait for a few minutes and then, log on again. After you see the messages about coupling to the CFs, run the following commands:
TERM CONMODE 3270
IPL A80 LOADP 0A82PSM1
This IPL command assumes that the sysres is on device A80 and the F1SYS1 volume is on device A82. The ‘PS’ in the load parm refers to member LOADPS in SYS1.IPLPARM.
Depending on the speed of your PC, it might take a few minutes for the NIP messages to start appearing on the console. After the messages start, you might be prompted to confirm that you want to Initialize the sysplex (reply R 00,I to that WTOR). Sometime later, you might be prompted with WTOR IGGN505A, which indicates that the CICS TS 5.1 link library is not accessible. If you see that message and you do not want CICS TS 5.1, reply CANCEL.
The system should not present any more WTORs.
You might notice some messages about failures to connect to log streams (specifically for RRS and OPERLOG). The reason for these messages is described in 3.4, “System logger” on page 29. To define the log streams and eliminate those messages, run the following jobs in data set SYSPLEX.PARALLEL.CNTL:
 
•LOGREREP
This job defines the log stream for LOGREC data. For information about enabling the use of this logstream, see 3.4.2, “LOGREC” on page 32.
•LOGRHC
This job defines the log stream that can be used by the z/OS Health Checker.
•LOGROPR
This job defines the OPERLOG log stream. For information about activating OPERLOG, see 3.4.3, “OPERLOG” on page 32.
•LOGRSMF
This job defines the SMF log stream. For more information about the use of SMF log streams, see 3.4.4, “System Management Facility” on page 33.
•LOGRRRS
This job defines the RRS log streams for Parallel and base sysplex modes. For more information about RRS and considerations for its log streams, see 3.4.1, “Resource Recovery Services” on page 30.
Tip: All of these jobs end with a return code of 12 the first time they are run, which is acceptable. The jobs are set up to delete and redefine the respective log streams. Because the log streams do not exist the first time that the job is run, the DELETE LOGSTREAM statement fails, but the other statements complete successfully.
Because there are so many log streams, checking the output from this job can be time-consuming. The quickest way to check is to run the D LOGGER,L command and check that all the log streams that are shown in Example 4-3 are defined in your system.
Example 4-3 Log streams defined by LOGRxxx jobs
ATR.ADCDPL.ARCHIVE RRS_ARCHIVE_1 000001 IN USE
ATR.ADCDPL.DELAYED.UR RRS_DELAYEDUR_1 000001 IN USE
ATR.ADCDPL.MAIN.UR RRS_MAINUR_1 000001 IN USE
ATR.ADCDPL.RESTART RRS_RESTART_1 000001 IN USE
ATR.ADCDPL.RM.DATA RRS_RMDATA_1 000001 IN USE
ATR.ADCDPL.RM.METADATA RRS_RM_META_1 000001 IN USE
ATR.S0W1.ARCHIVE *DASDONLY* 000000 AVAILABLE
ATR.S0W1.DELAYED.UR *DASDONLY* 000000 AVAILABLE
ATR.S0W1.MAIN.UR *DASDONLY* 000000 AVAILABLE
ATR.S0W1.RESTART *DASDONLY* 000000 AVAILABLE
ATR.S0W1.RM.DATA *DASDONLY* 000000 AVAILABLE
ATR.S0W1.RM.METADATA *DASDONLY* 000000 AVAILABLE
ATR.S0W2.ARCHIVE *DASDONLY* 000000 AVAILABLE
ATR.S0W2.DELAYED.UR *DASDONLY* 000000 AVAILABLE
ATR.S0W2.MAIN.UR *DASDONLY* 000000 AVAILABLE
ATR.S0W2.RESTART *DASDONLY* 000000 AVAILABLE
ATR.S0W2.RM.DATA *DASDONLY* 000000 AVAILABLE
ATR.S0W2.RM.METADATA *DASDONLY* 000000 AVAILABLE
HZS.HEALTH.CHECKER.HISTORY HZS_HEALTHCHKLOG 000000 AVAILABLE
IFASMF.GENERAL IFASMF_GENERAL 000000 AVAILABLE
IFASMF.S0W1 *DASDONLY* 000000 AVAILABLE
IFASMF.S0W2 *DASDONLY* 000000 AVAILABLE
SYSPLEX.LOGREC.ALLRECS SYSTEM_LOGREC 000000 AVAILABLE
SYSPLEX.OPERLOG SYSTEM_OPERLOG 000000 AVAILABLE
If a log stream is missing, refer to the output from the associated job and search for the corresponding DEFINE LOGSTREAM NAME(log_stream_name) statement. An example of the part of the output from the LOGRRRS job is shown in Example 4-4 on page 74. In this case, the IXG007E message indicates that an error was encountered while processing the previous statement (#116). In this case, statement 116 was a DEFINE LOGSTREAM for ATR.ADCDPL.RESTART. The IXG007E message indicated that the DATACLAS definition in the DEFINE LOGSTREAM referred to a data class that was not defined.
Example 4-4 Sample LOGRRRS job output
   LINE # CONTROL CARDS
    116 DEFINE LOGSTREAM NAME(ATR.ADCDPL.RESTART)
117 STRUCTNAME(RRS_RESTART_1)
118 LS_DATACLAS(LOGR24K)
119 HLQ(LOGGER)
120 LS_SIZE(10240)
121 MODEL(NO)
122 LOWOFFLOAD(20)
123 HIGHOFFLOAD(80)
...
...
IXG005I LOGR POLICY PROCESSING LINE# 116
IXG007E A STORAGE MANAGEMENT SUBSYSTEM (SMS) ATTRIBUTE CLASS IS UNDEFINED.
IXG447I LOGR POLICY PROCESSING FOUND AN ERROR BUT CONTINUES. RETCODE=00000008 RSNCODE=00000838
IXG003I LOGR POLICY PROCESSING ENCOUNTERED AN UNEXPECTED ERROR. DIAGNOSIS INFORMATION: 00000004 000003F6 0107001B 00000000
You also see many log streams the names of which start with START1. These streams are CICS log streams that are pre-defined in the LOGR CDS that is included with this package. Therefore, you do not need to set them up.
The CICS log stream staging and offload data sets are allocated in the CICS storage group (CICS01 and CICS02 volumes). The OPERLOG, LOGREC, Health Checker, SMF, and RRS log stream data sets (all with a high-level qualifier of LOGGER) are allocated on the volumes that are mounted with the storage attribute (F1SYS1 and WORK01, if you use the provided VATLST00 and VATLSTPS members).
It is suggested that the system is shut down at this point (run the S SHUTSYS command) and then, bring it back up.
After the restart, the system should automatically start using the OPERLOG and RRS log streams.
If you want to use the LOGREC log stream, run the SETLOGRC LOGSTREAM command or include that command in the VTAMPS member.
If you want to use the SMF log stream, edit the SMFPRMPS member and change the first line to say ACTIVE rather than NOACTIVE, and the second line to say RECORDING(LOGSTREAM) rather than RECORDING(DATASET). Then, activate the updated member by running the SET SMF=PS command.
If you want Health Checker to send its output to a log stream, run the F HZSPROC,LOGGER=ON,LOGSTREAMNAME=HZS.HEALTH.CHECKER.HISTORY command. You can also update the HZSPRMAD member of the ADCD.Z21F.PARMLIB data set so that the log stream is enabled automatically. For more information about the use of the HZSPRMxx member, see IBM Health Checker for z/OS User’s Guide, SC23-6843.
After system S0W1 initializes successfully, complete the following steps to start the other sysplex member:
1. Log on to S0W2 (the initial password is S0W2).
2. Run the following commands to load the S0W2 system:
TERM CONMODE 3270
IPL A80 LOADP 0A82PSM1
The S0W2 system comes up with no further intervention required.
4.4.1 Parallel sysplex implementation checklist
Because the implementation of the 2016 Sysplex Extensions Parallel Sysplex requires many steps and it is important at the steps are completed in the correct sequence, we provide the checklist in Table 4-5. You can use this checklist track your progress and ensure that you do not accidently omit or skip any steps.
Table 4-5 2016 Sysplex Extensions Parallel Sysplex implementation checklist
Task
Description
Done?
1
Install base ADCD z/OS system
 
2
Download/Install base ADCD z/VM system
 
3
Download and gunzip 5 2016 Sysplex Extensions volumes
 
4
Allocate 5 new volumes that use alcckd command
 
5
Create backup of z/VM and z/OS volumes before making changes
 
6
Add 2016 Sysplex Extensions volumes to devmap
 
7
Add commands to devmap to start x3270 sessions
 
8
Restart zPDT and IPL z/VM
 
9
Update VM Directory to add WRKALLEG keyword
 
10
Log on to BASEAD and IPL z/OS in monoplex mode
 
11
Initialize 5 new z/OS volumes
 
12
Run IMPCONN job to import connect user catalogs
 
13
Run VSAMS0W2 job Create S0W2 System VSAM data sets
 
14
Run VSAM1A, VSAM1B, and VSAM1C jobs to reallocate S0W1 page data sets
 
15
Run OMVSCLON job to create S0W2 copies of OMVS file systems
 
16
Run HZSALLCP job to allocate S0W2 Health Checker data set
 
17
Run RECATLG job to recatalog 2016 Sysplex Extensions CDSs in master catalog
 
18
Add S0W2 system name and sysplex name to SMS config
 
19
Add the following SMS data classes for Logger and DB2:
  LOGR4K
  LOGR24K
  DPDGDC
 
20
Create SMS storage class for CICS and DB2 data sets:
  PSADDON
 
21
Create SMS storage groups for CICS and DB2 data sets
  CICFILES
  DB2FILES
 
22
Update ACS routines to assign new data and storage classes and storage groups
 
23
Run ACDS5 job to change shareoptions of SMS CDSs
 
24
Update MASDEF statements in JES2PARM member
 
25
Run COPYPARM job to copy 2016 Sysplex Extensions parmlib members to USER.PARMLIB and SYS1.IPLPARM
 
26
Run COPYPROC job to copy 2016 Sysplex Extensions Proclib members to USER.PROCLIB
 
27
Create new TCP PROFILE and TCPDATA members in USER.TCPPARMS
 
28
Run COPYVTAM job to copy VTAMLST members to USER.VTAMLST
 
29
Reload BASEAD system in monoplex mode
 
30
Logoff BASEAD
 
31
AUTOLOG CF Virtual Machines from CFCONSOL user
 
32
Log on to S0W1 and IPL by using new Parallel Sysplex LOADPS member
 
33
Run LOGREREP job to define LOGREC log stream
 
34
Run LOGROPR job to define OPERLOG log stream
 
35
Run LOGRRRS job to define RRS log streams
 
36
Run LOGRSMF job to define SMF log stream
 
37
Run LOGRHC job to define Health Checker log stream
 
4.5 Other steps for base sysplex under z/VM
If your target environment is a base sysplex under z/VM, there are some other steps required. There are also some messages that can be ignored when you start a base sysplex under z/VM. In this section, we list those messages and describe the reasons why you are receiving them.
4.5.1 Changes to z/VM directory
Add definitions for virtual CTCs that are used for XCF communication between the members of the sysplex.
You can define these dynamically in each virtual machine that is connected via the CTCs (S0W1 and S0W2 in this case) by running the VM DEFINE command.
However, we believe that it is less work to add the definitions to the VM directory. To add these definitions, add the following statements to the directory entries for S0W1 and S0W2 (use the same definitions for both virtual machines):
SPECIAL E20 CTCA
SPECIAL E21 CTCA
SPECIAL E40 CTCA
SPECIAL E41 CTCA
SPECIAL E42 CTCA
SPECIAL E43 CTCA
After you make these changes, save the USER DIRECT C file and run the DIRECTXA USER DIRECT C command to update the directory.
You notice that these statements do not provide information about which CTC devices are connected to which other devices. For more information, see 4.5.3, “Bringing up your base sysplex” on page 78.
4.5.2 Changes in parmlib
From a parmlib perspective, the only thing that must be different in a base sysplex compared to a Parallel Sysplex is that GRS Star cannot be used in a base sysplex. The GRS parameter in IEASYSxx must specify something other than “STAR”.
This section describes the members that must be used when running in base sysplex mode under z/VM.
LOADxx member
Because you use the same z/VM virtual machines for base and Parallel Sysplex, you need some way to differentiate between base and Parallel Sysplex. This distinction is made by using a different LOADxx member when running in base sysplex mode. The LOADBS member points at IEASYMBS.
The LOADBS member is copied into SYS1.IPLPARM when you run the BASPARM job.
IEASYMBS member
The IEASYMBS member is identical to the IEASYMPS member, with the following exceptions:
•The IEASYMBS member sets the VTAMAPPL symbol to be VTAMBS, which is used by the START VTAMPS command in COMMNDPS.
•The IEASYMBS member adds one more member (IEASYSBS) to the sysparm concatenation.
The IEASYMBS member is copied into USER.PARMLIB when you run the BASPARM job.
IEASYSBS member
The IEASYSBS member contains one parameter (the GRS=TRYJOIN statement). All of the other IEASYSxx parms are picked up from IEASYS00 in ADCD.Z21F.PARMLIB or IEASYSPS in USER.PARMLIB.
SMFPRMBS
The SMFPRMBS member is identical to the SMFPRMPS member with the exception that it specifies system-unique log streams rather than a single log stream that is shared by both systems.
The SMFPRMBS member is copied into USER.PARMLIB when you run the BASPARM job.
VTAMBS member
The VTAMBS member starts each RRS with a different group name.
Now, run job BASPARM in SYSPLEX.PARALLEL.CNTL to copy these members into USER.PARMLIB and SYS1.IPLPARM.
4.5.3 Bringing up your base sysplex
There are some small changes to the IPL process if you are bringing up the systems in base sysplex mode.
Because the same virtual machines are used for Parallel and base sysplex modes, the systems automatically use the CFs if they are running and connected to the S0W1 and S0W2 machines. Therefore, you must ensure that the Coupling Facility Virtual Machines are not logged on. To do this, use the OPERATOR or MAINT ID and run a Q N command. If CFCC1 or CFCC2 appear in the list, run the following commands to stop them (having first shut down any z/OS systems that might be using them):
FORCE CFCC1
FORCE CFCC2
When running in a base sysplex under z/VM, the S0W1 and S0W2 systems communicate by using the CTCs that you defined in 4.5.1, “Changes to z/VM directory” on page 76. Before they can be used, you must connect the CTCs to each other. Although this connection must be done only from one of the virtual machines, S0W1 and S0W2 must be logged on before you can issue these commands. After both machines are logged on, run the following commands in S0W1:
COUPLE E20 S0W2 E21
COUPLE E21 S0W2 E20
COUPLE E40 S0W2 E41
COUPLE E41 S0W2 E40
COUPLE E42 S0W2 E43
COUPLE E43 S0W2 E42
You are now ready to start the systems in base sysplex mode. To do start the system in this mode, run the following command in one of the systems:
TERM CONMODE 3270
IPL A80 LOADP 0A82BSM1 (this loads the system by using the LOADBS member of SYS1.IPLPARM)
As with any time you load the first system in a sysplex, you might receive a WTOR asking if you want to initialize the sysplex. If you see that message, reply R 00,I. You should expect to see messages when the system is initializing that indicate it cannot access CFs CFCC1 or CFCC2. You see these message because the base sysplex is using the same CDSs (including the CFRM data set) as the Parallel Sysplex. Because you are coming up in base sysplex mode, you can ignore those messages.
When the first system finishes initializing, logon to TSO and browse back through syslog to verify that everything started as expected. If everything is OK, submit job LOGRRRS in SYSPLEX.PARALLEL.CNTL to allocate the DASDONLY log streams that are used by RRS on each system.
The OPERLOG and LOGREC log streams include fixed names. Base sysplex supports only DASDONLY log streams, and DASDONLY log streams cannot be shared across systems. In a base sysplex, a maximum of one system can use OPERLOG or LOGREC, which negates much of the value of those two functions. As a result, we did not provide jobs to create DASDONLY versions of the OPERLOG or LOGREC log streams.
Address any unexpected messages, then load the other system by using the same IPL address and load parameters. When that system is initializing, you should see messages that indicate that XCF is connecting to the other system by using the CTC addresses that you specified in the COUPLE commands.
4.6 Implementing a base sysplex without z/VM
The other option for running a base sysplex is more complex because it involves two PCs, cross-PC file sharing, Server Time Protocol (STP), and the use of a network to connect the PCs.
Base sysplex operation does not involve z/VM, but it does involve other details that must be set up correctly.
The base sysplex configuration involves multiple Linux machines. A Linux file sharing function, such as NFS, provides coordinated DASD functions at the Linux cache level. z/OS uses GRS functions, via the CTC links among z/OS systems, to coordinate data set sharing and other serialization. A synchronized time-of-day function is provided by the zPDT STP function6.
In the configuration that is shown Figure 4-4 on page 80, all of the emulated DASD for all z/OS partners are placed on one Linux machine (PC2), which becomes the Linux file server. In practice, the emulated DASD can be spread over several Linux machines, all of which can work as file sharing servers and clients. In Figure 4-4, the solid lines between the PCs and the switch represent the physical connections between the PCs. The dotted lines represent logical connections. In practice, all the traffic (STP, XCF, NFS, and so on) goes over the Ethernet connections.
Figure 4-4 Base sysplex without z/VM
4.6.1 Setting up and starting STP
One of the most basic requirements of any sysplex is that all the systems in the sysplex must have a common time source. When running a parallel or base sysplex under z/VM, z/VM provides the common time source. However, if the sysplex is spread over more than one PC, you need some other mechanism for keeping the System z clocks in sync; namely, STP.
The zPDT implementation of STP timer facilities is described in the STP chapter of IBM zPDT Guide and Reference System z Personal Development Tool, SG24-8205, which is available at this website:
To use STP, you must edit and configure the /usr/z1090/bin/CCT_data file on each PC. This file differs slightly on each member of the base sysplex because the IP address (or domain name) differs for each member.
In addition to updating the CCT_data file, you must update the devmap file to add the [stp] section. The STP chapter of IBM zPDT Guide and Reference System z Personal Development Tool, SG24-8205, includes clear, step-by-step, instructions for setting up these files. An example of the definitions from our devmap is shown in Example 4-5 on page 81.
Example 4-5 Sample stp definition statements from devmap file
[stp]
ctn 00000000F1F0F9F0
node 1 W520 *    # For the W510 system, the asterisk is
node 2 W510      # moved to the second node statement
After configuring this file on each sysplex member, verify that all the members of the base sysplex have TCP/IP connectivity to each other. This connection can be verified by using simple ping commands. Now, run the zPDT stpserverstart command on each member. In principle, running this command causes the STP functions to be started automatically whenever you start Linux. The stpserverquery command can be used to verify that STP is functioning as you expect.
4.6.2 Defining CTCs for XCF communication
Another requirement for a base or Parallel sysplex is that XCF in the systems in the sysplex must communicate with each other. If a system is trying to join the sysplex but cannot communicate over XCF to the other sysplex members, it is not allowed to join the sysplex.
Because a base sysplex does not have CF structures for XCF communication, it uses CTCs to communicate. In a zPDT sysplex that does not use z/VM, zPDT emulates the CTC function by using TCP/IP to communicate between the PCs. You can find all the information that you need with sample configurations in the channel-to-channel chapter of IBM zPDT Guide and Reference System z Personal Development Tool, SG24-8205, which is available at this website:
When z/VM is used to emulate the CTC function, you use the COUPLE command to tell which two CTC devices to connect. Similarly, with zPDT, you need to tell each zPDT the following information:
•Device number for each CTC device
•To which remote CTC it should connect
Because TCP/IP is used for the CTC communication, you use the IP address of the remote CTC by using the IP address of the remote Linux (you specify the IP address of the Linux system, not the address of the z/OS system). Sample definitions for two PCs are shown in Example 4-6 and Example 4-7.
Example 4-6 Sample devmap CTC definitions on PC1
[manager] #CTC definitions for PC1 in base sysplex
name awsctc 0088
device E40 3088 3088 ctc://192.168.1.99:4000/E41
device E41 3088 3088 ctc://192.168.1.99:4001/E40
Example 4-7 Sample devmap CTC definitions on PC2
[manager] #CTC definitions for PC2 in base sysplex
name awsctc 0088
device E40 3088 3088 ctc://192.168.1.230:4001/E41
device E41 3088 3088 ctc://192.168.1.230:4000/E40
As described in 4.5.3, “Bringing up your base sysplex” on page 78, the VM COUPLE commands connected CTC E40 in S0W1 to E41 in S0W2. XCF CTCs are unidirectional; that is, each CTC is a PATHIN (meaning that XCF messages are received on that device) or a PATHOUT (meaning that XCF messages are sent on that device). Therefore, you must always connect a PATHIN device to a PATHOUT device. The CTCs are defined by using the following statements in the COUPLEPS member:
/* DEFINE XCF TRANSPORT CLASS PATHS FOR BASE SYSPLEX  */
PATHIN DEVICE(E20) /* DEFAULT TC */
PATHIN DEVICE(E40) /* DEF8K TC */
PATHIN DEVICE(E42) /* DEF61K TC */
PATHOUT DEVICE(E21) CLASS(DEFAULT)
PATHOUT DEVICE(E41) CLASS(DEF8K)
PATHOUT DEVICE(E43) CLASS(DEF61K)
On system S0W1, you connect E20 (a PATHIN) to E21 (a PATHOUT) on S0W2, and E21 (a PATHOUT) to E20 (a PATHIN) on S0W2. Therefore, the devmap file should connect the CTCs devices to the opposite type of CTC on the target system. In the statements that are shown in Example 4-6, E40 on this system is connected to E41 on the remote system. Also, the port number for this connection is 4000. If you review the definition of device E41 on the other PC, you see that it specifies device number E40 as the target CTC device. It also specifies the same port number as the E40 definition on PC1. Similarly, E41 on PC1 is connected to E40 on PC2. But, this connection is using a different port number (4001) in this case. If you have multiple CTC connections, each one must use a different port number.
When you run the awsstart command on the second PC, you do not see any messages about the CTC connection unless there is a problem. If you want to check that the two PCs are connected, run the zPDT awsstat command.
4.6.3 Sharing zPDT DASD across PCs
Our base sysplex configuration requires shared DASD operation for all the emulated 3390 volumes. Setting up Linux shared directories is beyond the scope of this book.
The process that is used to share zPDT DASD across PCs includes the following steps on an openSUSE 13.1 system:
1. On our openSUSE Linux system that holds all of the emulated 3390 volumes, we used YaST functions to create an NFS server with the following parameters:
 – NFS server: Start
 – Firewall: (firewall is disabled; you might request opening a port in your firewall)
 – Enable NFSv4: yes
 – Enable GSE security: no
 – Directories to export: /z (this directory contained all our emulated volumes)
 – Host wild card: 192.168.1.230 (the address of our second system Linux)
 – Options: fsid=0,crossmnt,rw,root_squash,sync,no_subtree...
2. On our second Linux system, we defined mount point /z2 (owned by user ibmsys1) with read and write access by everyone. We selected this mount point to be different from the /z mount point that we normally use for local volumes (we did not want there to be any confusion about to which PC’s disks we were referring). We then used YaST services to define an NFS client with the following parameters:
 – NFS shares:
Server remote-directory mount-point NFS type options
192.168.1.99    /z /z2 nfs rw,defaults
 – Enable NFS4: yes
 – NFSv4 Domain Name: localdomain (use default value unless you know better)
 – Enable GSS Security: no
 – Firewall settings: (firewall is disabled)
3. In principle (perhaps after rebooting both systems), you should see the shared volumes from the second Linux system by running a command, such as ls /z2. In practice, we ran the following command on the second system (working as root) to see the shared volumes from the second system:
# mount -t nfs4 192.168.1.80:/ /z2
(We are not NFS experts and considerable experimentation at times was needed to make the sharing work.) Be certain that the rw (read/write) option is present on the NFS server and client.
4. Be certain the --shared option is present on the awsckd device manager statements in the devmaps on both systems. (This statement enables RESERVE/RELEASE emulation.) Be certain the devmap for the second system contains the correct mount points (/z2 in our example) for all the emulated disk volumes.
When the cross-PC file sharing is working, update the devmap file for the second PC to change the file names to include the z2.
 
Note: Although functional and sufficient for function testing, this configuration might not deliver the levels of performance that you require. If you can make a larger financial investment in improving the performance of a multi-PC zPDT configuration, see Appendix C, “Alternative disk configuration” on page 141.
4.6.4 Required parmlib changes
In addition to the infrastructure changes (STP, CTCs, and shared DASD) that are required to span the base sysplex across more than one PC, a few changes to parmlib are required. The systems must be told to use STP for their time synchronization, meaning that the CLOCKxx member must be updated (the ADCD default is to disable ETRMODE and STPMODE). You also need to configure GRS for Ring mode rather than Star mode. Also, each RRS must be started with a different group name to stop them from trying to share log streams.
LOADST member
You need some way to tell the system that it is to come up in base sysplex, not under z/VM mode. You also need a way to set system-specific system symbols. When running under z/VM, you can use the VM user ID as a filter in the IEASYMxx member. However, this sysplex is not running under VM so that method is not an option.
However, you can use the LPAR Name. When running under zPDT, the instance name (which is set to the Linux user ID that started zPDT) is loaded into the LPAR name field. Therefore, you can filter by using the LPARNAME field in your IEASYMxx member.
 
Important: When running a base sysplex that spans two PCs, you must start zPDT with a different Linux user ID on each system. Failing to use this configuration can result in problems because it appears that the same system is being loaded twice into the same sysplex.
Consider the following points:
•The LOADST member is identical to LOADPS, except that it points at IEASYMST.
•The LOADST member is copied into SYS1.IPLPARM when you run the STPPARM job.
IEASYMST
IEASYMST is identical to IEASYMPS with the exceptions that it filters based on the system name, and it specifies that the system uses IEASYS00, IEASYSPS, and IEASYSST when initializing.
 
Note: It is likely that you must customize the IEASYMST member. It is set up on the assumption that the two z/OS systems include instance names of IBMSYS1 and IBMSYS2. If the Linux user IDs that you use to start zPDT have different names, you must adjust this member.
The IEASYMST member is copied into USER.PARMLIB when you run the STPPARM job.
IEASYSST
The IEASYSST member contains only the following parameters:
•CLOCK : This parameter is set to ST to use the CLOCKST member.
•GRS : This parameter is set to TRYJOIN because it is a base sysplex.
The IEASYSST member is copied into USER.PARMLIB when you run the STPPARM job.
CLOCKST member
The ADCD-provided CLOCK00 member specifies NO for STPMODE and ETRMODE. Because a sysplex that spans more than one PC requires STP, you must use a CLOCKxx member that specifies STPMODE YES. Consider the following points:
•The ADCDST member is a complete replacement for the CLOCK00 member.
•The CLOCKST member is copied into USER.PARMLIB when you run the STPPARM job.
SMFPRMBS
The SMFPRMBS member is identical to the SMFPRMPS member with the exception that it specifies system-unique log streams rather than a single log stream that is shared by both systems.
The SMFPRMBS member is copied into USER.PARMLIB when you run the STPPARM job.
VTAMBS
The VTAMBS member starts each RRS with a different group name, which avoids both RRSs trying to share the log stream (cross-system log stream sharing is not possible in a base sysplex).
Run job STPPARM in SYSPLEX.PARALLEL.CNTL to copy these members into USER.PARMLIB and SYS1.IPLPARM.
4.6.5 Loading the systems
All of the pieces that are required to start a base sysplex without z/VM should be in place now. We strongly suggest allowing the first system to complete the entire startup process before you load the second system. We also recommend that you load the system that is in the same PC as the NFS server first.
With Linux sharing enabled, some operations are slower. For example, starting the second system (NFS client) with no connection to the NFS server causes the start function to be much slower. Loading the local system first might load the Linux cache with data that is used by the IPL, which provides a small benefit for later loads by remote systems. Even allowing for that benefit, a load of the second system is much slower than a load of the first system.
Both systems can be loaded by using the ipl a80 parm 0A82STM1 command.
As with any time you load the first system in a sysplex, you might receive a WTOR asking if you want to initialize the sysplex. If you receive that message, reply R 00,I. You can expect to see messages when the system is initializing that indicate that it cannot access CFs CFCC1 or CFCC2. You are seeing these message because the base sysplex is using the same CDSs (including the CFRM data set) as the Parallel Sysplex. Because you are coming up in base sysplex mode, you can ignore those messages.
When the first system finishes initializing, logon to TSO and browse back through the syslog to verify that everything started as expected. If everything is OK, submit job LOGRRRS in SYSPLEX.PARALLEL.CNTL to allocate the DASDONLY log streams that are used by RRS on each system.
The OPERLOG and LOGREC log streams have fixed names. Base sysplex supports only DASDONLY log streams, and DASDONLY log streams cannot be shared across systems. In a base sysplex, a maximum of one system can use OPERLOG or LOGREC, which negates a much of the value of those two functions. As a result, we did not provide jobs to create DASDONLY versions of the OPERLOG or LOGREC log streams.
Address any unexpected messages. Then, load the other system by using the same IPL address and load parameters. When that system is initializing, you should see messages that indicate that XCF is connecting to the other system by using the CTC addresses that you specified in the devmap file.
4.7 Operating your sysplex
After your sysplex finishes initializing, operating the systems should be similar to running in a normal monoplex environment, except for all the extra functions that are available.
For example, when you have a single system, there always is a concern that the system might not come back up after a change is made. When you have a sysplex, you can stay logged on on one system while you load the other system. If there is a problem, you now have a running, fully functional system that you can use to address whatever is stopping the system from loading.
4.7.1 Managing your x3270 sessions
At least five 3270 sessions are needed for the sysplex. If you try to squeeze all sessions onto the one window, the window can be cluttered, which makes it easy to enter commands in the wrong 3270 session.
We suggest that two Linux desktop workspaces with the arrangement that is shown in Figure 4-5 is used.7 The 3270 windows that are related to the S0W2 system are in the second workspace, which helps prevent confusion when the multiple 3270 windows are used. The 3270 addresses that are shown in Figure 4-5 correspond to the 3270 device addresses that are defined in the devmap file. An example of the interactions with the various x3270 sessions is provided in Appendix D, “Sample IPL flow for sysplex under z/VM” on page 145.
Figure 4-5 Sample lay out for x3270 sessions
4.7.2 Post-loading messages
If you use the S0W1 system in monoplex mode, you might see unusual messages during start because it appears to z/OS that systems in different LPARs are trying to use the same page data sets, as shown in the following example:
ILR030A PAGE DATA SET MAY BE IN USE
ILR031A REPLY 'U' TO PREVENT ACCESS, 'CONTINUE' TO ALLOW USE OF SYS1.....
r 00,continue <---your reply
In this case, ensure that only one system is using those page data sets. If it is, reply continue, as shown in the example.
4.7.3 SMF considerations
The default mode of operation for an ADCD system is for SMF collection to be disabled. In a purely development system (especially with one or a few users), you might find that you rarely use the SMF data. However, if you want to collect SMF records, the following options are available, depending on how you are running your systems:
•In a Parallel Sysplex, you can share a single log stream between both systems. This configuration is convenient because all of your SMF records are in a single location. You can leave the records in the log stream and have system logger automatically delete them after a retention period that is specified on the log stream (the SMF log stream that is delivered with the 2016 Sysplex Extensions has a retention period of 14 days, but you can change this setting at any time by updating the log stream definition). The log stream for Parallel Sysplex mode is called IFASMF.GENERAL.
•In a base sysplex, a log stream cannot be shared across multiple systems. However, you can still write the SMF data from each system to its own log stream. This configuration provides most of the benefits of the single log stream, with the exception that you no longer have a single repository of all SMF data. The log streams that we defined for base sysplex mode are called IFASMF.S0W1 and IFASMF.S0W2.
•In any mode (monoplex, base sysplex, or Parallel Sysplex), you can use the traditional SYS1.MANx VSAM data sets.
The 2016 Sysplex Extensions provides two SMFPRMxx members: SMFPRMBS and SMFPRMPS. Both members contain definitions for SYS1.MANx data sets with data set names that contain the system name (for example, SYS1.S0W1.MAN1). The SMFPRMBS member is used when the system is loaded by using a loadparm that indicates that it is to come up in base sysplex mode. That member contains definitions for the system-specific log stream name. The SMFPRMPS member is used when the system is brought up in Parallel Sysplex mode and it contains a definition for the shared log stream.
By default, SMF recording is disabled. If you enable recording, the default is to use the SYS1.MAN data sets. If you want to use the log streams instead, update the appropriate SMFPRMxx member to say RECORDING(LOGSTREAM) and run the SET SMF=xx command to get SMF to use the parms in the named member.
4.7.4 Sysplex policies
The sysplex policies that are provided by the 2016 Sysplex Extensions are sufficient to get the sample Parallel Sysplex (complete with CICSplex and DB2 data sharing) up and running. Nevertheless, it is likely that you will want to make changes to these policies over time. We recommend that you create a local copy of the provided jobs and make any changes that you want in those local copies. The sources for the provided policies are in the following members in SYSPLEX.PARALLEL.CNTL:
•POLARM1 : Automatic Restart Manager policy
•POLCFRM1: Coupling Facility Resource Management policy
•POLSFM1 : Sysplex Failure Management policy
•LOGRCICS : Defines CICS model log streams
•LOGREREP: Defines the LOGREC log stream
•LOGRHC : Defines the z/OS Health Checker log stream
•LOGROPR : Defines the OPERLOG log stream
•LOGRRRS : Defines the RRS log streams
•LOGRSMF : Defines the SMF log streams
If you want to change the ARM, CFRM, or SFM policies, we strongly recommend that you give the new policies a different name to the active policy. The policy name is specified on the NAME parameter on the DEFINE POLICY statement in the policy. When you activate the new policy, the policy name is specified in the SETXCF START,POLICY command. By using a different name, you can fall back to the old policy if there is a problem with the new policy.
The sources for the policies that are provided by the 2016 Sysplex Extensions are in Appendix B, “Sysplex couple data sets and policies” on page 127.
4.7.5 Shutdown
Although you might be tempted to shut down your system by ending it, this process can result in data loss and unexpected messages the next time the system is loaded. For these reasons, we strongly recommend taking the time to complete an orderly shutdown of your system. This suggestion applies to any system, but especially to a system in a zPDT Parallel Sysplex.
ADCD provides the VTAMAPPL tool to automate the start up and shut down of your system. The ADCD-supplied proc for this process is called SHUTALL. We created a slightly modified version called SHUTSYS. The SHUTSYS JCL is in USER.PROCLIB. It points at members SHUTS0W1 or SHUTS0W2 in USER.PARMLIB, depending on which system is being stopped.
Depending on which started tasks are running on your systems, you might want to customize these members to remove commands for started tasks that you do not use and add commands for your started tasks that are not included in the provided members.
The example shows how you perform an orderly shutdown of both systems (the numbers in parenthesis at the start of some lines refer to the device numbers that are used in Figure 4-5 on page 86):
logoff of all TSO sessions
(703) S SHUTSYS (start shutdown script for S0W2)
(wait for the ALL AVAILABLE FUNCTIONS COMPLETE message)
(703) $PJES2
(wait for the JES2 ENDED message)
(700) S SHUTSYS (start shutdown script for S0W1)
(wait for the ALL AVAILABLE FUNCTIONS COMPLETE message)
(700) $PJES2
(wait for the JES2 ENDED message)
(700) V XCF,S0W2,OFFLINE
nn IXC371D CONFIRM REQUEST TO VARY SYSTEM S0W2 OFFLINE, REPLY
SYSNAME=S0W2 TO REMOVE S0W2 OR C TO CANCEL
(700) nn,SYSNAME=S0W2
nn IXC102A XCF IS WAITING FOR SYSTEM S0W2 DEACTIVATION. REPLY DOWN
WHEN MVS ON S0W2 HAS BEEN SYSTEM RESET
(If you simply wait for about 15 seconds, z/VM will end S0W2 so there is no need to reply DOWN)
(wait for console activity to stop; usually after a CONSOLE
PARTITION CLEANUP COMPLETE message.)
(703) LOGOFF
(to log off the S0W2 virtual machine)
 
(700) V XCF,S0W1,OFFLINE (this allows PDSE, etc, to stop cleanly)
(700) nn,SYSNAME=S0W1
(700) LOGOFF
(to logoff the S0W1 virtual machine)
 
(CFCONSOL) FORCE CFCC1
(CFCONSOL) FORCE CFCC2
(CFCONSOL SHUTDOWN (shutdown z/VM)
(Linux 1) $ awsstop
The V XCF command and the response to the WTOR can be issued on either system, but must name the system that is being stopped. It is important to complete this step. If you do not complete this step, the other members of the sysplex might think that you are loading another system with a duplicate name (because you never cleanly removed it from the sysplex) the next time you attempt to load the system.
4.7.6 Useful commands
A few commands can be entered directly on a CFCC console. Because we use a common z/VM interface to the CFCC virtual machines, we must use the z/VM SEND command. The following examples direct CFCC commands (these are entered on the CFCONSOL terminal window) can be used:
SEND CFCC1 DISPLAY MODE
SEND CFCC2 DISPLAY RESOURCES
SEND CFCC1 DISPLAY CHPIDS
SEND CFCC2 HELP
Several z/OS commands are directly related to CF usage. In principle, the following commands are issued through the MVS operator console. In practice, some of the commands produce too much output to be useful on the MVS console panel and are best used through the SDSF LOG interface:
D CF Best use SDSF interface
D XCF Brief XCF status
D XCF,CF More detailed information
D XCF,COUPLE Lots of output; use SDSF interface
D XCF,POLICY
D XCF,STR List defined structures
D XCF,STR,STRNAME= ISGLOCK Details about specific structure; use SDSF
D LOGREC LOGREC status
D LOGGER ,L LOGGER status
V OPERLOG,HARDCPY If not already using LOGGER for some reason
SETLOGRC LOGSTREAM Change LOGREC recording
SET SMF=xx Switch to new SMFPRMxx member
The following z/OS commands are not directly related to CF usage, but are helpful in determining the state of the system:
D C,HC Hardcopy log status
D ETR External timer mode status
D C MVS console status
D IPLINFO
D M=CPU
D IOS,CONFIG
D M=STOR
$D MASDEF
$D MEMBER
The following Linux commands might be useful for base sysplex setup:
$ cat /etc/exports Used on an NFS server system
# showmounts -e Used on an NFS client system
4.7.7 Defining new CDSs
There might be situations where you want to move to new CDSs. For example, the supplied CDSs are formatted for a sysplex that contains up to four systems. If you want to have more than four systems in your sysplex, you must create a set of CDSs that are formatted with an appropriate MAXSYSTEM value.
The following basic mechanisms are available for moving to a new set of CDSs:
•Define the new CDSs (by using the DEFCDSS job in SYSPLEX.PARALLEL.CNTL as a model), and use the SETXCF ACOUPLE and SETXCF PSWITCH commands to copy the contents of the CDSs to the new CDSs.
•Shut down the sysplex, delete the data sets, define new (empty) data sets (by using the DEFCDSS job in SYSPLEX.PARALLEL.CNTL as a model), and bring the sysplex back up again.
 
Note: Most CDSs contain information that is constantly updated by the systems in the sysplex. In addition, some CDSs contain information (policies) that you create and place in the appropriate CDS; for example, ARM, SMF, or CFRM. If you delete and redefine the primary and alternative CDSs, all of that information is lost.
The first mechanism is almost always used in a production environment or any environment in which a sysplex-wide outage is unacceptable. It also has the advantage that all of the information (policies and status information) in the CDSs is carried forward to the new CDSs.
If you decide to use the first mechanism, the process includes the following steps:
1. Create a copy of the DEFCDSS job that allocates the data sets you require, along with the changes that you want to make (for example, larger MAXSYSTEM value).
2. Run a SETXCF ACOUPLE command to replace the alternative data set with the data set that becomes the new primary.
3. Run a SETXCF PSWITCH command to replace the primary data set with your new primary data set.
4. Run another SETXCF ACOUPLE command to add the new alternative CDS.
5. Update the COUPLEPS member of USER.PARMLIB to specify the new CDS names. This step ensures that the sysplex uses the correct data sets the next time that you load a system or the entire sysplex.
At the end of this process, you are running on the new CDSs and all the status and policy information from the corresponding old CDSs are carried forward.
However, if your objective is to discard all of the contents of the CDSs and start with a clean sheet, the process is more complex. It is especially important to understand that if you use the second mechanism to replace the Logger CDSs, all of the information in the existing log streams is inaccessible.
The process that is used to replace the CDSs by using the second mechanism includes the following steps:
1. Shut down the Parallel Sysplex and z/VM.8
2. Load the basic ADCD system (not under z/VM) with an IPL parameter, such as 0A82CS.
3. Using ISPF option 3.4, delete all the Parallel Sysplex CDSs on volume CF0001.9 Those data sets have names beginning with PARALLEL.ADCDPL. (Do not delete the CDSs that are used by the basic ADCD system. These data sets have names beginning with SYS1.ADCDPL and are on other volumes.)
You might also want to delete the logger offload data sets, as described in “Logger data sets” on page 92. Failing to delete these sets can result in confusing messages in the future because Logger attempts to allocate new staging and offload data sets with names that are duplicates of existing data sets.
4. Change whatever parameters you want in the coupling definitions in the DEFCDSS, and POLaaaa jobs in PARALLEL.SYSPLEX.CNTL.
5. Run job DEFCDSS to create the CDSs and verify that the job ends with return code zero.
6. Update the COUPLEPS member of parmlib to specify the new CDS names, if necessary.
7. Run the POLaaaa jobs to install your policies into the new CDSs.
 
Important: The default action when you run the IXCMIAPU utility to create a policy is to install that policy in the corresponding in-use CDS. However, you are running with the ADCD-provided CDSs in this case, but you want to install your new policies into the CDSs you just created. Therefore, it is vital to ensure that the POLaaaa jobs include the name of the target CDS on the DEFINE POLICY statement, as shown in Example 4-8.
This method can be used only with the ARM, CFRM, and SFM policies. It is not possible to update the LOGR policy in any data other than the active LOGR CDS.
Example 4-8 Sample IXCMIAPU statements
//POLARM1 JOB (0,0),CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID.
//ARMPOL EXEC PGM=IXCMIAPU
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSIN DD *
DATA TYPE(ARM) REPORT(YES)
DEFINE POLICY NAME(ARM1) DSN(SYSPLEX.ADCDPL.NEW.ARM.CDS01) REPLACE(YES)
8. If you created CFRM CDSs, update the COUPLEPS member to add the CFRMPOL(aaaaaa) statement. This step is necessary if you want to start in GRS Star mode and the CFRM CDSs being used for the IPL were not used previously.
9. Complete any other tasks that are easier in an unshared system.
10. Shut down the basic ADCD system.
11. Start z/VM, the two Coupling Facility Virtual Machines, and load the S0W1 system (with IPL parameter 0A82PS).
Several unexpected error messages might appear in the log. These messages occur because the various logstreams are not yet defined.
12. Run the following jobs from the SYSPLEX.PARALLEL.CNTL data set:
 – LOGRCICS for the CICS model log streams
 – LOGREREP for the LOGREC log stream
 – LOGRHC for the z/OS Health Checker log stream
 – LOGROPR for the OPERLOG log stream
 – LOGRRRS for the RRS log streams
 – LOGRSMF for the SMF log streams
Use the z/VM command DIAL S0W1 to access a VTAM session.
13. Edit the COUPLEPS parmlib member again and remove the CFRMPOL statement.
The extra CF structures are now available, but your S0W1 system is not using the structures that were added by the LOGRaaaa jobs. You can use the structures immediately by running the following MVS commands:
V OPERLOG,HARDCPY (starts OPERLOG operation)
SETLOGRC LOGSTREAM (moves LOGREC to the log stream)
SETSMF RECORDING(LOGSTREAM) (change SMF to use log stream mode)
S RRS,SUB=MSTR (restart RRS to use CF structures)
D XCF,STR (display the allocated structures)
The next time that you load (with IPL parameter PS), these log streams are used automatically.
Logger data sets
Be aware that the CDSs might contain data that is needed across IPLs. The most obvious case involves LOGGER staging and offload data sets. In normal use, LOGGER automatically deletes its offloaded data sets when the retention period for all the records in the data set expires. If you delete and re-create the CDSs, this retention period information for LOGGER data sets is lost and the data sets remain on your disks until they are explicitly deleted. These sets are VSAM data sets and are slightly more difficult to delete than simple sequential or partitioned data sets.
The LOGGER data sets normally have the high-level qualifier IXGLOGR (but have a HLQ of LOGGER or START1 for the CICS log streams in our parallel Sysplex system) and have full names, as shown in the following example:
IXGLOGR.IFASMF.GENERAL.A0000000 <==base cluster name
IXGLOGR.IFASMF.GENERAL.A0000000.DATA
IXGLOGR.SYSPLEX.LOGREC.ALLRECS.A0000000 <==base cluster name
IXGLOGR.SYSPLEX.LOGREC.ALLRECS.A0000000.D
or
LOGGER.IFASMF.GENERAL.A0000000 <==base cluster name
LOGGER.IFASMF.GENERAL.A0000000.DATA
LOGGER.SYSPLEX.LOGREC.ALLRECS.A0000000 <==base cluster name
LOGGER.SYSPLEX.LOGREC.ALLRECS.A0000000.D
The A0000000 qualifiers in these examples are for the first LOGGER data set in each group. This number is incremented when LOGGER data sets are created.
4.7.8 Adding 3390 volumes in Parallel Sysplex
You might want to add emulated 3390 volumes to one or both z/OS systems. The z/VM directory for the z/OS guests that is described in this chapter has directory definitions for z/OS 3390 volumes at addresses A80 - ABF, which might be sufficient for your extra volumes.
Complete the following steps:
1. Create (or restore) the volumes. Creating a volume involves the use of the zPDT alcckd command as described in 4.3.3, “Download and create volumes” on page 42.
2. Add the new volume to the devmap. The devmap file is used in our examples is called devmapp. Use an address in the A80 - ABF range, if possible. If this range cannot be used, complete the following steps to modify the z/VM directory:
a. Start zPDT (run the awsstart devmapp command) and IPL z/VM (run the ipl 200 parm 0700 command).
b. Log on as user maint (password is SSI110).
c. Edit the VM directory (run the xedit user direct c command).
d. Scroll to the section that begins with user ID MVSDUMMY.
e. For more information about the devices that are defined in the ADCD-provided IODF, see “Devices defined in the ADCD-provided IODF” on page 122. If possible, use an address that is defined to avoid having to update the IODF.
f. By using the patterns for user IDs MVSDUMMY, BASEAD, S0W1, and S0W2, add lines for your new volumes, if needed. Add these lines to all four user IDs.
g. Exit from Xedit (run the file command).
h. Rebuild the active z/VM directory (run the directxa user direct c command).
3. Start one of the z/OS systems. If you created 3390 volumes (instead of restoring the volumes from a DVD or a download), you must submit an ICKDSF job from TSO to initialize the volumes. (z/OS automatically varies offline any uninitialized volumes it finds during IPL. After you initialize the volumes with ICKDSF, you can vary them online to z/OS.)
4.7.9 Adding 3270 terminals in Parallel Sysplex
You can add more 3270 sessions for z/VM or for each z/OS. Consider the following points:
•z/VM must know about the extra local 3270 devices. This process is completed by adding 3270 definitions in the devmap. z/VM recognizes 3270 terminals, regardless of the addresses that are used. That is, it is not necessary to use addresses in the 7xx range (although our z/VM customization requires a local 3270 session at address 700 for the initial operator session). Remember that a maximum of 32 terminals can be defined for the aws3274 device manager. You might need to run a z/VM enable all command to obtain a logon logo on the new terminals.
•After you define the extra z/VM 3270 sessions, you can use these sessions to DIAL to a z/VM guest. For example, DIAL S0W1 to connect to our first z/OS system.
•The z/VM user ID definition for a guest (S0W1, S0W2, and BASEAD) must have sufficient SPECIAL statements for all of the 3270 sessions (except the session at address 700 that is used for the MVS console). You can add SPECIAL statements for these user IDs by editing the z/VM directory, as described in 4.7.8, “Adding 3390 volumes in Parallel Sysplex” on page 92. These SPECIAL connections are hardware connections between a 3270 session and the guest z/OS virtual machine.
•z/OS must recognize the 3270 session. The current ADCD systems recognize local 3270 connections at addresses 701 - 73F. However, the A0600 member in VTAMLST allows only 10 TSO sessions through local 3270 connections. You must modify VTAMLST to increase this number; this task is a normal z/OS systems programming activity.
•You can connect 3270 sessions to z/OS TCP/IP. The current ADCD systems allow up to 30 such connections (through definitions in the TCPIP PROFILE and in VTAMLST). These sessions11 (directly to z/OS TCP/IP) do not require any modifications to z/VM or the devmap.
4.7.10 Scaling up in Parallel Sysplex
Some of the limitations of the starter system that we described are important to understand. It is a relatively small configuration and various steps are required to expand it to a larger, more robust, configuration. In particular, consider the following points:
•Our two z/OS systems are defined (in the z/VM directory) with a modest amount of memory for each. Depending on the products that are used in the system and the volume of work that is processed, the system might require much more memory.
•Our sample devmap defines an 8 or 10 GB zPDT system. This devmap must be increased to accommodate the larger z/OS systems.
•Larger z/OS systems often require larger paging data sets. If large virtual memory applications (such as DB2 applications) are used and if SVC memory dumps might be expected, considerably larger paging areas are required for each z/OS. The MVS command D ASM is useful for determining the amount of paging space that is used. Under SDSF, the DA function can be used to informally sample dynamic paging rates.
•Larger z/VM and z/OS memory should have correspondingly larger PC server memory.
•Our z/VM system has one 3390-3 volume for paging. More z/VM paging volumes might be needed. Monitor for HCPPGT401I and HCPPGT400I messages on the VM OPERATOR console. These messages can precede a VM wait state; therefore, if you encounter these messages, add more paging volumes to z/VM before you add more work to z/OS.
•Our CFs (in the z/VM directory) are defined with 1200 MB each. Depending on the number and size of your coupling structures, these CFs might need to be larger. Run a D CF command on z/OS to determine how much free space you have in each CF. We strongly suggest that you aim for each CF not being more than 50% full to allow for moving all the structures into one CF if you must restart the other CF.
•Our z/OS systems have limited STORAGE disk space (as defined in the VATLST00 members in PARMLIB). You might need to add disk volumes that are defined as STORAGE volumes.
•SVC memory dumps are directed to F1SYS1 and F1SYS2. You might want to direct them to larger volumes that you add.
•You should monitor paging and swap space in your base Linux. The xosview program is convenient for this process if you installed it with your Linux.
Paging (by the base Linux, z/VM, or z/OS) often is a poor use of the limited disk I/O resources in a zPDT system. Larger PC memory, which is combined with a small amount of monitoring to best balance memory usage, can be the most effective way of improving the performance of the zPDT systems. Despite these efforts, you are likely to see base Linux swap activity; this activity appears to be mostly because of a strong Linux preference to use real memory for the disk cache. An effective disk cache is important for zPDT performance.
 
1 In theory, it should be possible to use the 2016 Sysplex Extensions with some small modifications to create a Parallel Sysplex that is based on an appropriately licensed Rational RD&T environment.
2 The F1PRDn volumes contain various products and you might not need all of them; see the ADCD documentation for more information about the contents of each volume.
3 If you are using zPDT release 6, you must use z/VM 6.3, or z/VM 6.2 with the APARs that are required to support IBM z13™. These APARs are required even though you are not running on a real z13.
4 All of the z/OS parts of the 2016 Sysplex Extensions installation can be done in a z/OS that is running natively under zPDT rather than under z/VM. However, that configuration eliminates the opportunity to gain experience with z/VM before starting your sysplex. It also means having to go back through all the steps in this chapter and selecting the z/VM-related steps. However, if your target environment is a base sysplex spanning multiple PCs, it is not necessary to use z/VM.
5 If you do not adjust the region size, the job might end with a return code 12 and message ICK31327I.
6 The zPDT STP function requires zPDT GA6 or later.
7 Another option is to use a separate PC for the 3270 sessions that are related to the S0W2 system.
8 This step also can be done by using the BASEAD guest under z/VM. When this approach is used, you must stop the two coupling facility virtual machines after you stop and log off the S0W1 and S0W2 virtual machines.
9 Our installation example in this chapter uses this volser; other volumes can be used.
10 This password is the password for the z/VM 6.3 ADCD system. Other z/VM implementations feature their own passwords.
11 There is a limit of 30 because of TN3270 and VTAM definitions. These limits can be increased, if needed.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.224.32.86