This chapter provides the MVS host software configuration for VLE, as described in the following sections:
The following sections describe values required for software configuration that must match values that are typically already set in the hardware configuration, and recorded in the IP_and VMVC_Configuration.xls worksheet.
The subsystem name of the VLE, which is set by the VLE installation scripts, is specified, as follows:
Either the VTCS CONFIG TAPEPLEX STORMNGR parameter or the CONFIG STORMNGR NAME parameter
The VTCS CONFIG RTD STORMNGR parameter
The SMC STORMNGR NAME parameter
The SMC SERVER STORMNGR parameter
The HSC STORCLAS STORMNGR parameter
The VTSS Ethernet port addresses are required to configure the VTSS-to-VLE IP connection through the CONFIG RTD IPIF parameter. For VSM 5s, this value must match the values specified on the VSM5 IFF Configuration Status screen. For VSM 6s, this must be unique for each VTSS, but does not correspond to an actual value on the VSM 6 TCP/IP ports.
The IP addresses of VLE port for host (UUI) communication are required for the SMC SERVER IP parameter.
Required to define VMVCs to SMC/VTCS, method of definition depends on the software version. See "Defining the VLE VMVCs to the MVS Host Software and Including VMVCs in an MVC Pool."
For more information, see "Specifying the Reclamation Policy for VMVCS."
The STORCLAS DEDUP parameter specifies whether VTV data migrated to VMVCs in the specified STORMNGR is deduplicated. For example:
STORCLAS NAME(VLEDEDUP)STORMNGR(VLE1) DEDUP(YES)
This STORCLAS statement specifies to deduplicate data in Storage Class VLEDEDUP that is migrated to VLE1. For more information, see ELS 7.3 Command, Control Statement, and Utility Reference.
Deduplication increases effective VMVC capacity and is performed by the VLE before the VTV is written to a VMVC. Oracle recommends, therefore, that you initially enable deduplication, then monitor the results with the SCRPT report and fine tune deduplication, as necessary.
ETTFB (also known as the concurrent tape recall/mount feature) allows host applications to read data while VTVs are being recalled from either VMVCs or RTDs. ETTFB is done by overlapping the VTV recall and mount phases, which allows the application to read the VTV data sooner. If the application attempts to read a part of the VTV that has not been recalled, the applications' I/O request is blocked until the required VTV data has been recalled. With ETTFB for VLE, application access to the first byte occurs in under a second, making the VLE a true extension of the VTSS. Therefore, VLE ETTFB is a good choice for applications that serially access the VTV data. VLE ETTFB is generally not a benefit for those applications that stack multiple files on a single VTV, including HSM and image management applications. In these types of applications, the desired data is usually not at the beginning of the VTV, but rather, at some random location in the VTV.
ETTFB is disabled by default. You can globally enable ETTFB through the CONFIG GLOBAL FASTRECL parameter. If you globally enable ETTFB, you can disable it for individual VTSSs through the CONFIG VTSS NOERLYMNT parameter.
VTVs that have incurred an ETTFB recall error have an error flag set in their VTV record in the CDS. These VTVs are subsequently not selected for ETTFB. If you want to reset the error flag, do any of the following:
Enter a VTVMAINT SCRATCH(ON) command for the VTV.
Migrate the VTV to a new MVC copy.
Import the VTV.
Create a new version of the VTV.
Scratch the VTV.
Adding VLE to a VSM system requires the tasks described in the following sections:
For more information on the commands and control statements referenced in this chapter, see ELS 7.x Command, Control Statement, and Utility Reference.
For ELS 7.2 and later, support is included in the base level. For ELS 7.1, get the latest SMP/E receive HOLDDATA and PTFs (L1H16J6, L1H1674) and SMP/E APPLY with GROUPEXTEND.
The VLE requires SMC to have an OMVS RACF security entry to have a TCP/IP connection to the host.
OMVS is a segment associated with the RACF userid. The SMC started task must have a userid associated with OMVS, either in the RACF STARTED class definition or the ICHRIN03 LNKLST module. The userid associated with the SMC task needs to have an OMVS segment defined to it within RACF, as follows:
ADDUSER userid DFLTGRP(groupname)OWNER(owner)OMVS(UID(uidnumber))
Or, if the userid already exists but does not have an OMVS segment:
ALTUSER userid OMVS(UID(uidnumber))
SMC manages all communication between VTCS and VLE, so SMC must know how to connect to the VLE server. To do so, add an SMC STORMNGR statement for each VLE system plus one or more SMC SERVER statements that define the TCP/IP control paths for the VLE. For 7.0 and later, you may want to do this in your SMC CMDS file, as shown in Example 2-1.
Example 2-1 SMC Commands for VLE
TAPEPLEX NAME(TMVSA)LOCSUB(SLS0) SERVER NAME(ALTSERV) TAPEPLEX(TMVSA) + HOSTNAME(MVSX) PORT(8888) STORMNGR NAME(VLE1) SERVER NAME(VLE1)+ STORMNGR(VLE1)IP(192.168.1.10)PORT(60000)
Example 2-1 contains:
A TAPEPLEX statement, which defines a single TapePlex, TMVSA, with an HSC/VTCS running on the same MVS host (SLS0).
A SERVER statement, which defines a backup HSC/VTCS subsystem (ALTSERV) running on another host.
A STORMNGR command that defines a VLE (VLE1).
A second SERVER command that defines a UUI communication path to the VLE, where:
The server name is VLE1.
The STORMNGR parameter value is VLE1.
The IP parameter value is the VLE port IP address of 192.168.1.10 for UUI communications.
The PORT parameter value is 60000; this value is always used for the SERVER PORT parameter for SMC communication with a VLE.
You must update VTCS CONFIG deck to define the VLE and the connectivity from the VTSS systems to the VLE. VTCS can drive VLE, as follows:
For VTCS 7.0 and later, the CONFIG TAPEPLEX statement defines the TapePlex that VTCS is running under and provides the list of defined VLEs on the CONFIG TAPEPLEX STORMNGR parameter, as shown in Example 2-2.
Example 2-2 VTCS 7.0 CONFIG VLE
TAPEPLEX THISPLEX=TMVSA STORMNGR=VLE1 VTSS NAME=VTSS1 LOW=70 HIGH=80 MAXMIG=8 MINMIG=4 RETAIN=5 RTDPATH NAME=VL1RTD1 STORMNGR=VLE1 IPIF=0A:0 RTDPATH NAME=VL1RTD2 STORMNGR=VLE1 IPIF=0A:1 RTDPATH NAME=VL1RTD3 STORMNGR=VLE1 IPIF=0I:0 RTDPATH NAME=VL1RTD4 STORMNGR=VLE1 IPIF=0I:1 RTDPATH NAME=VL1RTD5 STORMNGR=VLE1 IPIF=1A:0 RTDPATH NAME=VL1RTD6 STORMNGR=VLE1 IPIF=1A:1 RTDPATH NAME=VL1RTD7 STORMNGR=VLE1 IPIF=1I:0 RTDPATH NAME=VL1RTD8 STORMNGR=VLE1 IPIF=1I:1 VTD LOW=6900 HIGH=69FF
In Example 2-2, note:
The CONFIG TAPEPLEX statement, which defines TMVSA as the TapePlex that VTCS is running under, and the names of all connected VLEs, (which, in this example, is a single VLE called VLE1).
The CONFIG RTDPATH statements, which define a single VLE RTD for each path from the VTSS to the VLE. In this example, the CONFIG RTDPATH statements for VTSS1 specify:
The name of the RTDPATH.
The connections to the defined VLEs (STORMNGR=VLE1).
The IPIF value for each VTSS-to-VLE port connection in ci:p format where:
c is 0 or 1.
i is A or I.
p is 0 through 3.
Note:
For VSM 5s, this value must match the values specified on the VSM5 IFF Configuration Status Screen. For VSM 6s, this must be unique for each VTSS but does not correspond to an actual value on the VSM 6 TCP/IP ports.VTCS 7.1 and later, systems can, of course, drive VLE 1.5.1 as VTCS 7.0 does. In this mode, however, the number of VLE RTD targets is limited by the number of paths from a VTSS. Additionally, the VLE RTDs are assigned to fixed VTSS paths. The path from a VTSS to the VLE is always reserved by VTCS regardless if any VTSS-to-VLE data transfer is occurring.
However, with VTCS 7.1 and later, you can define a VLE with more VLE RTD targets than there are paths from the VTSS to the VLE, which means:
The path from the VTSS to the VLE is not reserved unless a VTSS-to-VLE data transfer is required.
More VLE RTD operations can occur simultaneously. For example, an audit of a VMVC does not require a data transfer between the VTSS and the VLE.
As shown in Example 2-3, the VLEs are defined through a CONFIG STORMNGR statement, not the CONFIG TAPEPLEX STORMNGR parameter. The CONFIG STORMNGR statement specifies the VLEs that VTCS connects to. Additionally, for each VLE, the CONFIG STORMNGR VLEDEV parameter defines the number and the names of the RTD devices that the VLE emulates. The more devices defined (up to the maximum of 96 devices per VLE), the greater the level of concurrent activities VTCS can schedule on the VLEs.
Example 2-3 VTCS 7.1 CONFIG VLE
TAPEPLEX THISPLEX=TMVSC STORMNGR NAME=VLE1 VLEDEV(S000-S05F) STORMNGR NAME=VLE2 VLEDEV(S000-S05F) VTSS NAME=VTSS1 LOW=70 HIGH=80 MAXMIG=8 MINMIG=4 RETAIN=5 RTDPATH NAME=VL1RTD1 STORMNGR=VLE1 IPIF=0A:0 RTDPATH NAME=VL1RTD2 STORMNGR=VLE1 IPIF=0A:1 RTDPATH NAME=VL1RTD3 STORMNGR=VLE1 IPIF=0I:0 RTDPATH NAME=VL1RTD4 STORMNGR=VLE1 IPIF=0I:1 RTDPATH NAME=VL1RTD5 STORMNGR=VLE2 IPIF=1A:0 RTDPATH NAME=VL1RTD6 STORMNGR=VLE2 IPIF=1A:1 RTDPATH NAME=VL1RTD7 STORMNGR=VLE2 IPIF=1I:0 RTDPATH NAME=VL1RTD8 STORMNGR=VLE2 IPIF=1I:1 VTD LOW=6900 HIGH=69FF
In Example 2-3, note:
The CONFIG TAPEPLEX statement now simply defines TMVSC as the TapePlex that VTCS is running under. It does not define the connected VLEs.
The CONFIG STORMNGR statements, which define the VLEs configured in this system - VLE1 and VLE2, specify the number of VLE devices through the VLEDEV parameter.
In this example, each VLE has the maximum of 96 emulated devices, allowing VTCS to schedule up to 96 processes on each VLE. The VLE device addresses are in the form of Sxxx (where xxx is a hexadecimal value).
Example: S000-S05F represents 96 emulated devices.
The CONFIG RTDPATH statements for VTSS1, which specify:
The name of the RTDPATH
The connections to the defined VLEs (STORMNGR=VLE1, STORMNGR=VLE2)
The IPIF value for each VTSS to VLE port connection in ci:p format where:
c is 0 or 1
i is A or I
p is 0 through 3
Note:
For VSM5s, this value must match the values specified on the VSM5 IFF Configuration Status screen. For VSM 6s, this must be unique for each VTSS, but does not correspond to an actual value on the VSM 6 TCP/IP ports.VLE MVC media (VMVCs) is subject to fragmentation and must be reclaimed just like real MVCs. The VMVC reclaim process, however, uses far fewer resources than a standard reclaim. The reclaim threshold for a VMVC is specified through the CONFIG RECLAIM VLTHRES parameter. The lower that you set VLTHRES, the more frequent VTCS will run reclaim on the VMVCs, leading to greater, effective capacity of the VMVS (less fragmentation).
VMVC volsers must be defined both to the MVS host software and to the VLE. The VMVCs are defined to the VLE as a part of the VLE configuration. The following sections describe how to define the VMVCs to the MVS host software.
Code HSC POOLPARM or VOLPARM statements to define the VMVC pools.
For example, to define two separate pools for VLE1 and VLE2:
POOLPARM NAME(LEPOOL1)TYPE(MVC) VOLPARM VOLSER(VL0000-VL880) POOLPARM NAME(LEPOOL2)TYPE(MVC) VOLPARM VOLSER(VL2000-VL2880)
Run SET VOLPARM to validate the POOLPARM or VOLPARM statements.
SET VOLPARM APPLY(NO)
APPLY(NO) validates the statements without loading them. If you like the results, proceed to the next step. Otherwise, rework the volume definitions along with this step, and if the definitions are valid, proceed to the next step.
Run SET VOLPARM to load the POOLPARM or VOLPARM statements.
SET VOLPARM APPLY(YES)
The following sections tell how to update the MVS host software policies to direct data to the VLE system.
Management Classes specify how VTCS manages VTVs. The HSC MGMTclas control statement defines a Management Class and its attributes. For example, the DELSCR parameter of the MGMTclas statement specifies whether VTCS deletes scratched VTVs from the VTSS. Management Classes can also point to Storage Classes, which specify where migrated VTVs reside. The HSC STORclas control statement defines a Storage Class and its attributes. You specify the VLE system as the destination for migrated VTVs through the STORCLAS STORMNGR keyword. For example:
STOR NAME(VLOCAL) STORMNGR(VLESERV1) DEDUP(YES) STOR NAME(VREMOTE) STORMNGR(VLESERV2)DEDUP(YES)
The preceding statements define a ”local” Storage Class (VLOCAL) on the VLE1 and a ”remote” Storage Class (VREMOTE) on the VLE2. As these STORCLAS statements specify, all migrations to storage class VLOCLAL or VREMOTE must go to the specified VLEs. Deduplication is specified for both Storage Classes.
You can be less restrictive than this, if desired. For example, if you define an MVCPOOL that contains both VMVCs and MVCs, you can setup the migration policies to migrate to a VLE. However, if the VLE becomes full or not available, continue to migrate to real tape media (MVCs). For example, the MVC pool DR is defined, as follows:
POOLPARM NAME(DR)TYPE(MVC) VOLPARM VOLSER(VL0000-VL0100) VOLPARM VOLSER(ACS000-ACS099)
Pool DR, therefore, contains both MVCs and VMVCs. A Storage Class that specifies pool DR will migrate first to VMVCs and only use MVCs if VMVCs are not available.
Example:
STOR NAME(DRCLASS) MVCPOOL(DR)DEDUP(YES)
This method is valuable if you have a configuration where both an ACS and a VLE are connected to the VTSS systems.
Next, to specify migration to VLE, you specify the VLE Storage Classes you defined through the MGMTCLAS MIGPOL parameter. For example:
MGMT NAME(M1) MIGPOL(VLOCAL,VREMOTE) MGMT NAME(M2) MIGPOL(DRCLASS)
Management Class M1 migrates one VTV copy to the ”remote” VLE, one copy to the ”local” VLE. Management Class M2 migrates a single VTV copy to the Storage Class that points to the ”mixed” MVC pool that contains both MVCs and VMVCs.
Note:
In addition to directing migration to a VLE also consider:If you are running at ELS 7.0 or higher, you can use HSC MIGRSEL and MIGRVTV to fine tune migration to VLE. Using these statements, you can cause migration of data in a Management Class to start to one Storage Class before another. This method is typically used to ensure that a critical DR copy is made as soon as possible. For more information, see Configuring HSC and VTCS.
On a VLE 1.1 and later system, if multiple VLEs are connected to each other and to the VTSS, by default, VTCS preferences VLE-to-VLE connections to make multiple VTV copies. You can control this behavior, as described in Controlling VLE-to-VLE Copy.
For VLE-to-VLE connections, if a VTV copy resides on both a VTSS and one VLE, and you want to migrate it to a connected VLE, the default is to use the VLE-to-VLE connection. For example, a DR scenario with a local VLE (LOCVLE) and remote VLE (REMVLE) connected to VTSSA. You want to migrate two VTV copies:
First, a local copy from VTSSA to LOCVLE.
Second, a copy using VLE-to-VLE copy from LOCVLE to REMVLE using VLE-to-VLE Replication (Versus VTSS-to-VLE migration).
To make the VTV copies as desired, do the following:
Create a STORCLAS statement that sends a VTV copy to LOCVLE.
STORCLAS NAME(FORLOCAL) STORMNGR(LOCVLE)
Create a STORCLAS statement that sends a VTV copy to REMVLE.
STORCLAS NAME(FORREMOT) STORMNGR(REMVLE)
Create MGRVTV statements that specify that migrates to Storage Class FORLOCAL occur before migrates to Storage Class FORREMOT.
MIGRVTV STOR(FORLOCAL) INITIAL MIGRVTV STOR(FORLOCAL) SUBSEQNT(360)
Finally, create a MGMTCLAS statement that specifies two VTV copies, one to the local site and the other to the remote site:
MGMTCLAS NAME(DRVLE) MIGPOL(FORLOCAL,FORREMOT)
To route data to VLE, first create an SMC POLICY command that specifies a VLE Management Class. Next, create SMC TAPEREQ statements that route the desired workload to the SMC VLE policy. For example:
POLICY NAME(VLEDR) MEDIA(VIRTUAL) MGMT(DRVLE)
TAPEREQ DSN(HR.**) POLICY(VLEDR)
The preceding example assigns the VLEDR policy to all tape datasets with an HLQ of HR.