2 Configuring the MVS Host Software

This chapter provides the MVS host software configuration for VLE as described in the following sections:

• "Key Configuration Values"

• "MVS Host Software Configuration Tasks"

Key Configuration Values

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.

Subsystem Name

The subsystem name of the VLE, which is set by the VLE installation scripts, is specified in the following:

• 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

VTSS Ethernet Port Addresses

The VTSS Ethernet port addresses are required to configure the VTSS to VLE IP connection through the CONFIG RTD IPIF parameter. 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.

IP Addresses of VLE Ports for Host (UUI) Communication

These addresses are required for the SMC SERVER IP parameter.

VMVC Volsers

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".

VMVC Reclamation Threshold

For more information, see"Specifying the Reclamation Policy for VMVCS".

VTV Deduplication

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.x 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.

Early Time to First Byte (ETTFB)

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 part of the VTV that has not been recalled, the application's I/O request is blocked until the required VTV data is 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 a 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.

MVS Host Software Configuration Tasks

Adding VLE to a VSM system requires the tasks described in the following sections:

• "Acquire the ELS supporting PTFs for VLE 1.4"

• "Updating the SMC OMVS RACF Security Entry"

• "Modifying the SMC SCMDS file"

• "Updating the VTCS CONFIG Deck to Define VLE"

• "Defining the VLE VMVCs to the MVS Host Software and Including VMVCs in an MVC Pool"

• "Updating the MVS Host Software Policies"

For more information on the commands and control statements referenced in this chapter, see ELS 7.x Command, Control Statement, and Utility Reference.

Acquire the ELS supporting PTFs for VLE 1.4

For ELS 7.2, support is included in the base level. For ELS 7.0 and 7.1, get the latest SMP/E receive HOLDDATA and PTFs described in Figure 1–1 and SMP/E APPLY with GROUPEXTEND.

Table 2-1 ELS Supporting PTFs for VLE 1.4

ELS 7.0	ELS 7.1
L1H16C1	L1H16J6
L1H1672	L1H1674

Updating the SMC OMVS RACF Security Entry

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))

Modifying the SMC SCMDS file

SMC manages all communication between VTCS and VLE, so SMC must know how to connect to the VLE server. You do so by adding 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 above, 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

Updating the VTCS CONFIG Deck to Define 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 1.4 as follows:

• For VTCS 7.0 and above, 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 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.

    
    

• VTCS 7.1 and above systems can, of course, drive VLE 1.4 as VTCS 7.0 does as described . 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 of whether any VTSS to VLE data transfer is occurring.

  However, with VTCS 7.1 (with the PTFs described in Table 2-1) and above, you can define a VLE with more VLE RTD targets then 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 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 in this example. These statements also specify the number of VLE devices through the VLEDEV parameter. In this example, each VLE has the maximum of 96 emulated devices, which allows 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. For 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.

    
    

Specifying the Reclamation Policy for VMVCS

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 and the greater the effective capacity of the VMVS (less fragmentation).

Defining the VLE VMVCs to the MVS Host Software and Including VMVCs in an MVC Pool

VMVC volsers must be defined both to the MVS host software and to the VLE. The VMVCs are defined to the VLE as part of the VLE configuration. The following sections tell how to define the VMVCs to the MVS host software.

Creating VMVC Volume Pools (7.0 and Above)

1. Code HSC POOLPARM/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) 
   

2. Run SET VOLPARM to validate the POOLPARM/VOLPARM statements.

   SET VOLPARM APPLY(NO)
   

   APPLY(NO) validates the statements without loading them. If you like the results, go to Step 3. Otherwise, rework your volume definitions, rerun this step, and if the definitions are valid, then go to Step 3.

3. Run SET VOLPARM to load the POOLPARM/VOLPARM statements.

   SET VOLPARM APPLY(YES)
   

Updating the MVS Host Software Policies

The following sections tell how to update the MVS host software policies to direct data to the VLE system.

Creating Storage and Management Classes for VLE

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. Also note that 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 set up the migration policies to migrate to a VLE but if the VLE becomes full or not available, to 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. For 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:

1. You can use the ARCHAge and ARCHPol parameters of the MGMTclas statement to set an Archive Policy for VTVs in a Management Class. When the VTV's age exceeds the ARCHAge value, the VTV is eligible for archive per the Storage Class(es) specified on the ARCHPol parameter. You can use Archive Policies to archive (move) VTVs from VMVCs to MVCs as the VTVs age. For more information, see Managing HSC and VTCS.

2. You can use STORSEL statements to cause VTCS to preference recalls from VLE media. For more information, see Managing HSC and VTCS.

3. If you are running at ELS 7.0 or above, 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.

4. On a VLE 1.1 and above 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 FROMLST Parameter Use.

FROMLST Parameter Use

If you do not specify FROMLST, the default behavior is as follows:

• For Clustered VTSSs, if a copy resides on multiple VTSSs in the cluster, the VTV can be sourced from any available VTSS, which may not be optimal if the VTSS and the connected ACS are geographically distant from each other.

• 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. Similarly, this may not be optimal if the connected VLEs are geographically distant from each other.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.VLE to VLE Replication (Versus VTSS to VLE)

To make the VTV copies as desired, do the following:

1. Create a VTSSLST statement to create a VTSS list that contains only VTSSA.

   VTSSLST NAME(VSM2VLE) VTSS(VTSSA)
   

2. Create a STORCLAS statement that sends a VTV copy to REMVLE.

   STORCLAS NAME(FORREMOT) STORMNGR(REMVLE)
   

3. Create a MIGRVTV statement that delays the migration copy to REMVLE.

   MIGRVTV STOR(FORREMOT) IMMDELAY(360)
   

   The migration delay is 360 minutes to allow the migration to the local site occur first; then the migration to the remote site is by VLE-to-VLE copy. Note that 360 minutes is just an example value, you can specify values of up to 9998 (do not specify 9999, because then the VTV is only migrated using automigration).

4. Create a STORCLAS statement that sends a VTV copy to LOCVLE.

   STORCLAS NAME(FORLOCAL) STORMNGR(LOCVLE) FROMLST(VSM2VLE)
   

   
   

   Note: Note that the FROMLST parameter specifies that the local VTV copy is sourced from VTSSA.

   
   

5. Finally, create a MGMTCLAS statement that specifies two VTV copies, one to the local site and one to the remote site:

   MGMTCLAS NAME(DRVLE) MIGPOL(FORLOCAL,FORREMOT)
   

Routing Data to VLE

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(VLEWORK) MEDIA(VIRTUAL) MGMT(VLECLASS)

TAPEREQ DSN(VLETEST.**) POLICY(VLEMIGR)

The preceding example assigns he VLEWORK policy to all tape datasets with an HLQ of VLETEST.