If you license VTCS, you must configure VTCS with the VTCS CONFIG utility. Refer to the ELS Command, Control Statement, and Utility Reference for information about this utility.
Much of the CONFIG process involves defining to VTCS the essential virtual/hardware parts of the VSM solution: VTSSs, VTVs, VTDs, and RTDs. What you also have the option of doing is setting non-default operating values, which is discussed in Chapter 2, "Planning VTCS Operating Policies."
Tip: ELS no longer requires you to define VTVs and MVCs using CONFIG. Now, it is done through POOLPARM/VOLPARM statements, which you created in "Defining MVCs" and "Defining VTVs."
This chapter includes two major CONFIG sections:
"Building a Simple CONFIG Deck" is basically a procedure where you build a sample basic CONFIG deck step-by-step in an ordered fashion, as described in Table 6-1.
"Special Cases: Advanced Uses of CONFIG" shows variations of the CONFIG deck beyond the basic model, such as the deck where you disable a host from initiating migrations.
Table 6-1 VTCS Configuration Tasks
| Step | Notes | Planning Information |
|---|---|---|
|
1 |
Are you doing an upgrade install? Then you want to run DECOMP to get a true picture of your current configuration. You can then update the DECOMP listing and resubmit it to CONFIG to update your configuration. Typically, you run DECOMP with the highest level of the VTCS (6.0 or 6.1) that supports the CDS "from" level. Or is this a first time install? If so, skip to Step 2. |
NA |
|
2 |
The actual CDS level specification is pretty easy but deciding which level takes some thought, so please study the planning section carefully before you begin coding. |
|
|
3 |
Specify global operating policies, such as the number of free MVCs. Remember, you can always take the defaults, and change things later. |
|
|
4 |
Specify the MVC reclamation policies. |
|
|
5 |
Specify CONFIG statements for the system's VTSSs, the RTDs attached to the VTSSs, and the VTDs in each VTSS. These statements complete the hardware definitions. |
The following procedure shows how to build a simple CONFIG deck. For more complex examples, see "Special Cases: Advanced Uses of CONFIG."
Caution:
Oracle strongly recommends that you do not "pre-define" hardware through the CONFIG deck (for example, by defining VTSSs that are not physically installed but will be in the future). Only use CONFIG to define hardware that is actually installed.Run the VTCS DECOMP Utility if you are performing an upgrade install. Otherwise, skip to Step 2.
The following example shows JCL to run the DECOMP utility with output to flat file CFG22202.
//DECOM EXEC PGM=SLUADMIN,PARM='MIXED' //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //SLSCNTL DD DSN=hlq.DBASEPRM,DISP=SHR //SLSCNTL2 DD DSN=hlq.DBASESEC,DISP=SHR //SLSSTBY DD DSN=hlq.DBASETBY,DISP=SHR //CFG22202 DD DSN=hlq.CFG22202,DISP=SHR //SLSPRINT DD SYSOUT=* //SLSIN DD * DECOM FLATDD(CFG22202)
The following example shows CONFIG JCL to specify CDS level G.
//CREATECF EXEC PGM=SLUADMIN,PARM='MIXED' //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //SLSCNTL DD DSN=hlq.DBASEPRM,DISP=SHR //SLSCNTL2 DD DSN=hlq.DBASESEC,DISP=SHR //SLSSTBY DD DSN=hlq.DBASETBY,DISP=SHR //SLSPRINT //SLSIN DD *DD SYSOUT=* CONFIG CDSLEVEL(V62ABOVE)
Note:
In this example, for VTCS NCO support, you do not have to specify RESET. RESET is not required when going from F to G level but all hosts accessing the CDS must be at VTCS/NCS 7.0 or above during the CDS level change. Refer to the ELS Command, Control Statement, and Utility Reference for details about when RESET is required.Specify global values.
The following example shows a CONFIG deck containing global values. Note that the example specified a Coupling Facility Structure to hold VTCS Lock Data:
The Structure must be predefined as shown in "Defining the Coupling Facility Structure to MVS."
You now have to specify RESET and all hosts must be down to implement or remove a VTCS Lock Structure within a Coupling Facility.
//CREATECF EXEC PGM=SLUADMIN,PARM='MIXED' //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //SLSCNTL DD DSN=hlq.DBASEPRM,DISP=SHR //SLSCNTL2 DD DSN=hlq.DBASESEC,DISP=SHR //SLSSTBY DD DSN=hlq.DBASETBY,DISP=SHR //SLSPRINT DD SYSOUT=* //SLSIN DD * CONFIG RESET CDSLEVEL(V62ABOVE) GLOBAL MAXVTV=65000 MVCFREE=60 VTVATTR=SCRATCH RECALWER=YES LOCKSTR=STK_VTCS_LOCKS VTVPAGE=LARGE MAXRTDS=32 FASTMIGR=YES
Tip: If a Lock Structure is already defined to VTCS, you can use DECOMP, Display CONFIG, and Display LOCKS to display information about the Lock Structure.
Specify reclamation policy values. The following example shows a sample CONFIG deck, now displaying reclamation policy values.
//CREATECF EXEC PGM=SLUADMIN,PARM='MIXED' //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //SLSCNTL DD DSN=hlq.DBASEPRM,DISP=SHR //SLSCNTL2 DD DSN=hlq.DBASESEC,DISP=SHR //SLSSTBY DD DSN=hlq.DBASETBY,DISP=SHR //SLSPRINT DD SYSOUT=* //SLSIN DD * CONFIG RESET CDSLEVEL(V62ABOVE) GLOBAL MAXVTV=65000 MVCFREE=60 VTVATTR=SCRATCH RECALWER=YES LOCKSTR=STK_VTCS_LOCKS VTVPAGE=LARGE MAXRTDS=32 FASTMIGR=YES RECLAIM THRESHLD=70 MAXMVC=30 START=40 CONMVC=5
Define VTSSs, RTDs, and VTDs.
The following example shows a sample CONFIG deck that defines VTSSs, the RTDs attached to each VTSS (both VSM4s), and the VTDs in each VTSS. Note that the RTD and VTD definitions immediately follow the VTSS statement. Also note that the CMDCONN and IPCONN parameters define the VTSS to host connection as TCP/IP.
//CREATECF EXEC PGM=SLUADMIN,PARM='MIXED'
//STEPLIB DD DSN=hlq.SEALINK,DISP=SHR
//SLSCNTL DD DSN=hlq.DBASEPRM,DISP=SHR
//SLSCNTL2 DD DSN=hlq.DBASESEC,DISP=SHR
//SLSSTBY DD DSN=hlq.DBASETBY,DISP=SHR
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
CONFIG RESET CDSLEVEL(V62ABOVE)
GLOBAL MAXVTV=65000 MVCFREE=60 VTVATTR=SCRATCH RECALWER=YES
LOCKSTR=STK_VTCS_LOCKS VTVPAGE=LARGE MAXRTDS=32 FASTMIGR=YES
RECLAIM THRESHLD=70 MAXMVC=30 START=40 CONMVC=5
VTSS NAME=VSM41 LOW=70 HIGH=80 MAXMIG=8 MINMIG=4 RETAIN=5 +
CMDCONN=TCPIP IPCONN=(192.80.12.1,192.80.12.2)
RTD NAME=PR11A00 DEVNO=1A00 CHANIF=0C
RTD NAME=PR11A01 DEVNO=1A01 CHANIF=0D
RTD NAME=PR11A02 DEVNO=1A02 CHANIF=0K
RTD NAME=PR11A03 DEVNO=1A03 CHANIF=0L
RTD NAME=PR12A08 DEVNO=2A08 CHANIF=1C
RTD NAME=PR12A09 DEVNO=2A09 CHANIF=1D
RTD NAME=PR12A0A DEVNO=2A0A CHANIF=1K
RTD NAME=PR12A0B DEVNO=2A0B CHANIF=1L
VTD LOW=9900 HIGH=99FF
VTSS NAME=VSM42 LOW=70 HIGH=80 MAXMIG=8 MINMIG=4 RETAIN=5 +
CMDCONN=TCPIP IPCONN=(192.80.12.3,192.80.12.4)
RTD NAME=PR23A00 DEVNO=3A00 CHANIF=0C
RTD NAME=PR23A01 DEVNO=3A01 CHANIF=0D
RTD NAME=PR23A02 DEVNO=3A02 CHANIF=0K
RTD NAME=PR23A03 DEVNO=3A03 CHANIF=0L
RTD NAME=PR24A08 DEVNO=4A08 CHANIF=1C
RTD NAME=PR24A09 DEVNO=4A09 CHANIF=1D
RTD NAME=PR24A0A DEVNO=4A0A CHANIF=1K
RTD NAME=PR24A0B DEVNO=4A0B CHANIF=1L
VTD LOW=9900 HIGH=99FF
To update your tape management system (such as CA-1, CA-Dynam/TLMS, and DFSMSrmm), do the following:
Add volser ranges for VTVs to your tape management system. Ensure that you do not assign vault codes to VTVs.
Access to the MVCs through an RTD bypasses the MVS intercepts put in place by the tape management system so that it does not record within its database any access to the MVCs by VSM and does not automatically provide protection against inadvertent overwrites of non-expired data on MVCs. Therefore, if you choose to define MVCs to the tape management system, Oracle strongly recommends that you define them as non-scratch, non-expiring volumes.
The tape management system requires an entry in the MVS Subsystem Name Table; this entry must precede the entry for SMC.
If you are using AutoMedia for MVS, ensure that VTVs are defined as virtual volumes to direct AutoMedia to bypass DSN checking, which allows AutoMedia to recall, mount, and reuse non-resident scratch VTVs.
Caution:
Note the following:VTCS has an automatic interface to notify RMM when a VTV becomes scratch but RMM does not notify VTCS when you unscratch a VTV by changing the CV status to non-scratch. If this is done, you must also run the HSC SLUADMIN utility to unscratch the VTV for VTCS. Otherwise, you may encounter a mount failure when VTCS attempts to select the VTV to service a scratch mount request.
RMM (DFSMS/RMM) has additional integrity checks at mount time to ensure that the correct volume has been mounted. Because VTCS has features and optimizations that sometimes present a new initialized version of a VTV rather than the current copy of a VTV, it is necessary for VTCS to override these RMM integrity checks. VTCS does these overrides using the LISTVOLUME and CHANGEVOLUME API calls to update the RMM database. You must therefore ensure that HSC has been given the appropriate security access to the RMM API. For more information, refer to your RMM documentation.
When VSM needs to mount an MVC and to write to an MVC, a SAF query is issued to verify that the HSC user (see "Defining A Security System User ID for HSC and VTCS") has UPDATE authority for the MVC. The SAF query is issued on behalf of HSC and passed to the system security product (such as RACF, CA-ACF2, or CA-Top Secret).
VSM requires UPDATE authority for the volsers in the MVC pool. All other users should have an access of NONE for these volsers. Similarly, VSM should not have UPDATE authority for any volsers that are not in the MVC pool. Refer to the documentation for your security product for procedures to add the appropriate tape volume security for VSM. Table 6-2 summarizes these definitions.
Table 6-2 Security Class, Resource Class, and Access Values for MVC Pool Volser Authority
| Class | Resource Name | Recommended User Access Levels |
|---|---|---|
|
Tape volume security |
MVC Pool Volume Serials |
UPDATE - allows VSM to write on MVC |
The following example shows a sample RACF profile and permissions commands to give the user ID VSM8HSC update access to MVC volser CVC024.
******************************************************************************** * Define a profile in the TAPEVOL security class for MVC CVC024 * ******************************************************************************** RDEFINE TAPEVOL security CVC024 UACC(NONE) ******************************************************************************** * Allow user ID VSM8HSC update access to MVC CVC024 * ******************************************************************************** PERMIT CVC024 CLASS(TAPEVOL) ACCESS(UPDATE) ID(VSM8HSC) ********************************************************************************
Caution:
Note the following:To ensure that MVCs are not accidentally overwritten, for each MVC volser, you must update your TAPEVOL security as described above and your tape management system. For more information, see "Updating the Tape Management System for VSM."
You must also run the HSC UNSCratch Utility to unscratch any current scratch cartridges in the MVC range. For more information, refer to Managing HSC and VTCS.
Depending on the default settings of your security system, VSM may not be able to mount and to write to MVCs until you have defined a security system user ID for HSC and TAPEVOL profiles for the MVCs.
If you add new ranges of MVCs to your VSM system, remember to update the TAPEVOL profiles to include the new ranges.
Before VTCS updates a CDS record (for example, a VTV record) it locks the record to avoid contention from concurrent updates from multiple hosts. VTCS releases the CDS lock record once the CDS record has been updated.
Customers with large VTCS configurations experience high CDS I/O rates, part of which is due to the need to access CDS lock records. As configurations grow in size, (for example, by adding more hosts), CDS performance becomes a bottleneck.
An MVS Coupling Facility is a suitable alternative medium for VTCS Lock data because:
A Coupling Facility provides very fast data transfer speeds, so the new I/O to the Coupling Facility with Lock records is less than the corresponding I/O to a CDS with Lock records.
MVS provides a technique that allows data stored in a failing Coupling Facility to be re-built in another Coupling Facility (if one exists) without terminating the application.
Note:
If VTCS locks are held in a coupling facility structure, VTCS uses the Structure (rather than the HSC mechanism) for sending/receiving Host-to-Host messages.Storing VTCS lock data in a Coupling Facility Structure is a solution to the specific problem of VTCS causing high I/O demand to the CDS in some configurations.
Note:
VTCS locks in a Coupling Facility Structure only works if all your hosts are within the same sysplex. Using SMC client/server feature is another solution to the problem that does not require all hosts to be within the same sysplex. Refer to Configuring and Managing SMC for more information.
Using a Coupling Facility Structure is not a solution to all CDS performance issues. For this reason, Oracle recommends that if you believe you have a CDS performance problem, contact Oracle Software support to have the problem analyzed before considering implementing VTCS lock data in a Coupling Facility.
To store VTCS Locks in a Coupling Facility:
All hosts must have access to the same Coupling Facility. Similarly, if you have an alternate Coupling Facility to rebuild the VTCS Lock Structure, all hosts must have access to that alternate Coupling Facility. All hosts must also be in a Sysplex.
The Coupling Facility implementation currently assumes all hosts run HSC/VTCS. VTCS will not start successfully on a host running HSC/VTCS if a host running HSC only is already active.
The Coupling Facility Structure must be predefined to MVS before VTCS can use it to store CDS Lock Records. VTCS uses the list form of a Coupling Facility Structure. Display LOCKS shows one of the following VTCS Coupling Facility lock types:
used to serialize access to the host footprint list.
used to serialize access to a given host to host list.
used to serialize access to the VTCS lock data.
used to serialize the initial formatting of the structure; also used when rebuilding data.
lock is held but is not a lock used by VTCS; assume it is used by MVS.
A Structure size of 768K should be sufficient for configurations up to 100 VTSSs. If the Structure is sized too small, HSC/VTCS will be unable to connect to the Structure or will be able to connect but will be unable to format all of its data. In both cases, VTCS will terminate.
The following example shows a sample of an IXCMIAPU job to define a VTCS Lock Structure within a Coupling Facility Resource Manager (CRFM). In this example, note that:
There are two Coupling Facilities, FACIL01 and FACIL02.
There is a 768K Structure called STK_VTCS_LOCKS to store VTCS Lock Records.
Structure STK_VTCS_LOCKS can exist in either Coupling Facility but FACIL01 is preferred over FACIL02. If VTCS starts to store lock data in FACIL01 and FACIL01 then becomes unavailable, VTCS attempts to build the STK_VTCS_LOCKS in FACIL02 to ensure continuous operations.
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
DATA TYPE(CFRM) REPORT(YES)
DEFINE POLICY NAME(POLICY1) REPLACE(YES)
CF NAME(FACIL01)
TYPE(123456)
MFG(IBM)
PLANT(02)
SEQUENCE(123456789012)
PARTITION(1)
CPCID(00)
SIZE(0)
DUMPSPACE(2000)
CF NAME(FACIL02)
TYPE(123456)
MFG(IBM)
PLANT(02)
SEQUENCE(123456789012)
PARTITION(2)
CPCID(00)
SIZE(1)
DUMPSPACE(2000)
STRUCTURE NAME(STK_VTCS_LOCKS)
SIZE(768)
PREFLIST(FACIL01,FACIL02)
Note:
If you define only one Coupling Facility, and it becomes unavailable, VTCS terminates on all hosts but HSC will still be running. If this occurs, do one of the following:Fix the Coupling Facility error, then recycle HSC/VTCS on all hosts; you can resume without changing the configuration.
If the Coupling Facility cannot be fixed:
Stop HSC on all hosts.
Remove LOCKSTR=structure_name from the VTCS configuration, then run the CONFIG utility with the RESET parameter (required to remove LOCKSTR=structure_name).
Restart the HSCs. The locks will now be maintained in the CDS.
To revert to storing VTCS Lock Data in the CDS:
Stop HSC on all hosts.
Run CONFIG RESET without the LOCKSTR parameter so VTCS can store VTCS Locks in the CDS.
Restart HSC/VTCS on all hosts.
Refer to VTCS Command and Utility Reference for more information.
VTCS supports Structure Rebuild to allow for failures/unavailability of the Structure or the Coupling Facility containing the Structure.
Structure rebuild can be initiated by:
Operator command (SETXCF START,REBUILD,xxx) for a planned outage of the Structure or the Coupling Facility, and/or
MVS or VTCS detecting an error in, or failure of, the Structure or the Coupling Facility.
Note that VTCS does not support System Managed Duplexing.
If the Structure used by VTCS can only be allocated in one Coupling Facility, VTCS will terminate on all Hosts if the Structure (or the Coupling Facility containing the Structure) fails or becomes unavailable.
If the Structure can be allocated in more than one Coupling Facility, VTCS's Structure Rebuild code will attempt to rebuild the data in an alternate Coupling Facility Structure. VTCS will only terminate if the rebuild fails.
If a resource is locked (not available), the request cannot be processed and is retried later. At present, error message SLS6946E is issued to provide information about resources that are not available for a period of ten minutes or more because they are locked by another host or task in the system.
The optional GLOBAL CONFIG LOCKTOUT=nnn parameter specifies a value of 0 or a value between 5 and 240. If a value of 0 is specified, message SLS6946E is not issued when a required resource is locked. A value between 5 and 240 specifies the minimum number of minutes that a resource is locked before message SLS6946E is issued. If the parameter is not specified, the default value is 10 minutes. The LOCKTOUT parameter requires F level CDS (V61ABOVE) and above and ELS 7.0 PTF L1H1665 or ELS 7.1 PTF L1H166E.
VSM7 VTSS supports 512 VTDs with current maintenance.
During VTCS and SMC initialization, any VTDs not explicitly defined in VTCS CONFIG are dynamically discovered. Only 256 VTDs can be defined in the VTCS CONFIG, the remaining VTDs are dynamically discovered.
The CONFIg VTSS CMDCONN parameter controls which path (channel or TCP/IP) VTCS uses to send commands to the VTSS. With CMDCOMM=CHANNEL, the default, only the VTDs defined in CONFIg VTD statements are used to send commands to the VTSS. Therefore, it is recommended to define as many VTDs (up to 256) as possible to CONFIG. CMDCOMM=TCPIP does not have this requirement.
The z/OS HCD configuration must be used to control which hosts have access to the VTDs that are not explicitly defined in the VTCS CONFIG.
To configure 512 VTD support:
Update the IOCP. See Appendix K, "VSM 6/VSM 7 Configuration."
Update the VSM7 or higher with the microcode that supports 512 VTDs.
Update ELS with the current maintenance.
Update the CONFIg GLOBAL statement by specifying VTDGT256=YES.
If necessary, update the CONFIg VTD control statements.
Run the CONFIg utility.
Start SMC and HSC.
Note:
If both SMC and HSC are running with 512 VTD support, then 512 VTD support can be implemented by varying the VTSS offline and then online.
The HSC Mount and DISMount commands do not support VTDs that are not defined in the VTCS CONFIG. The SMC Mount and DISMount commands must be used in place of the HSC Mount and DISMount commands for any VTDs that are not specified in the VTCS CONFIG.
If necessary, 512 VTD support can be updated or disabled globally for each VTSS.
To update or disable 512 VTD support:
Update the CONFIg GLOBAL statement with VTDGT256=YES or disable support for a specific VTSS update with CONFIg VTSS NOGT256.
Vary the MVS addresses for VTDs 256 – 511 offline.
Vary the VTSS offline and then online.