4 Configuring HSC

Before you configure VTCS, you must configure HSC if you are a new customer. If you are an existing customer, go to "Reconfiguring a TapePlex."

Your task list for configuring HSC is as follows:

• "Creating the HSC CDS"

• "Defining Volumes to ELS"

• "Adding Definitions for ACF/VTAM Communications"

• "Defining the SYS1.PARMLIB Member SMFPRMxx"

• "Creating the HSC PARMLIB Member"

• "Defining Command Authority"

• "Updating HSM"

• "Creating and Cataloging the HSC Startup Procedure"

• "Performance Considerations"

  Note:

  For information on routing data sets to VSM, refer to Configuring and Managing SMC.

Creating the HSC CDS

For real tape configurations, creating the CDS consists of the following:

• "Coding the LIBGEN Macros"

• "Running the SLICREAT Utility To Format the New CDS"

For more information on the LIBGEN macros, see "HSC LIBGEN Macros."

For only Tapeless VSM configurations (no RTDs attached, can have VLEs attached), see "Running the SLUADMIN CDSCREAT Utility to Create the CDS (Tapeless VSM Only)."

Caution:

It is critical that you control user access privileges to the CDS. See "Limiting CDS Access Privileges" for more information.

Coding the LIBGEN Macros

The LIBGEN macros specify the library configuration. You code the LIBGEN macros in a data set pointed to by the assembler JCL SYSIN DD statement. Table 4-1 describes the LIBGEN macros and shows their required order in the input data set. "LIBGEN Macro Samples" shows examples of LIBGEN input data sets. For more information on the LIBGEN utility, refer to the ELS Command, Control Statement, and Utility Reference. For more information on the LIBGEN macros, see "HSC LIBGEN Macros."

Caution:

Oracle strongly recommends that you do not "pre-define" hardware through the LIBGEN process (for example, by defining transports that are not physically installed but will be in the future). Only use the LIBGEN process to define hardware that is actually installed. If you need to add hardware after performing an initial LIBGEN, use the techniques described in "Reconfiguring a TapePlex."

Table 4-1 LIBGEN Macros

Macro	Description
SLIRCVRY	Specifies HSC recovery values.
SLILIBRY	Specifies global settings. You can also define future ACSs with SLILIBRY.
SLIALIST	Specifies the list of ACSs.
SLIACS	To define the ACSs, create one SLIACS macro for each ACS listed in the SLIALIST macro.
SLISTATN	Specifies the list of the stations (LMU interfaces) that connect a host to an ACS. Specify one SLISTATN macro for each station entry listed in the SLIACS macro.
SLILSM	To define each LSM, create one SLILSM macro for each LSM listed in the SLIACS macro LSM, LSM2, LSM3, and LSM4 parameters.
SLIDLIST	To define the transport list for each LSM, create one SLIDLIST macro for each DRVELST parameter entry in the SLILSM macro. This SLIDLIST macro lists the SLIDRIVS macros for each host.
SLIDRIVS	Specifies the transport device addresses used by each host attached to an LSM.
SLIENDGN	Specifies the end of the LIBGEN macros.

To make this LIBGEN procedure real-world, create an input file step-by-step that ends up looking like the example file shown in "One Host, Two ACSs, One 9310 LSM, One SL8500 Library Configuration."

To create an example LIBGEN input file:

1. Create the SLIRCVRY macro:

   LIBGEN01 SLIRCVRY TCHNIQE=ALL
   

   In this macro, you specified the label for the generated CSECT, and specified all 3 copies of the CDS.

   The TCHNIQE parameter on the SLIRCVRY LIBGEN macro determines how many CDS copies will be initialized by the SLICREAT program and whether or not journals will be initialized by SLICREAT. If journaling is specified by the TCHNIQE parameter, journals must be defined before HSC will successfully initialize.

2. Create the SLILIBRY macro:

   SLILIBRY HOSTID=HSC1,                                          X
          SMF=255,                                                X
          COMPRFX=#,                                              X
          ACSLIST=NAMEACS,                                        X
          MAJNAME=STKALSQN,                                       X
          SCRLABL=SL,                                             X
          EJCTPAS=GOODAY,                                         X
          CLNPRFX=CLN,                                            X
   

   In this macro, you specified the following:

   • Only host HSC1 accesses the configuration.

   • The SMF record type, here 255, which must match the type specified in "Defining the SYS1.PARMLIB Member SMFPRMxx."

   • # is the operator command prefix character.

   • NAMEACS is the assembler label of the SLIALIST macro.

   • STKALSQN is the ENQ/DEQ/QNAME used by host software for serialization.

   • Put Standard Labels on scratch volumes.

   • GOODAY is the eject password.

   • CLN is the cleaning cartridge prefix.

3. Create the SLIALIST macro:

    NAMEACS  SLIALIST  ACS00,ACS01
   

   In this macro, you specified the following:

   • The assembler label is indeed NAMEACS, as specified in the SLILIBRY macro.

   • ACS00 and ACS01 are the two ACSs.

4. Create the SLIACS macro for ACS00:

   ACS00    SLIACS STATION=(ST000), X
   LSM=(LSM0000)
   

   In this macro, you specified the following:

   • The assembler label is indeed ACS00, as specified in the SLIALIST macro.

   • The STATION parameter specifies ST000 as the assembler label of the SLISTATN macro.

   • The LSM parameter specifies LSM0000 as the assembler label of the (single) SLILSM macro for the 9310 LSM.

5. Create the succeeding macros referenced by the ACS00 SLIACS macro, starting with SLISTATN:

   ST000    SLISTATN  ADDRESS=(0A0,0A1)
   

   In this macro, you specified the following:

   • The assembler label is indeed ST000, as specified in the SLIACS macro.

   • The ADDRESS parameter specifies 0A0 and 0A1 as the device addresses of the two LMUs that control the 9310 LSM.

6. Create the SLILSM macro for the 9310 LSM:

   LSM0000  SLILSM    DRIVE=(1,2,9,10),                                   X
                  DRVELST=(P000001,P000002,P000009,P000010),              X
                  TYPE=9310,                                              X
                  DOOR=ECAP
   

   In this macro, you specified the following:

   • The assembler label is indeed LSM0000, as specified in the SLIACS macro.

   • The DRVELST parameter specifies P0000001, P0000002, P0000009, and P000010 as the assembler labels of the SLIDLIST macros that define the transports in each transport panel.

   • The LSM type is 9310.

   • The access door has an Extended CAP.

7. Create the SLIDLIST and SLIDRVS macros for the 9310 LSM:

   P000001  SLIDLIST  HOSTDRV=D0000010
   *
   D0000010 SLIDRIVS  ADDRESS=(410,411,412,413)
   *
   P000002  SLIDLIST  HOSTDRV=D0000020
   *
   D0000020 SLIDRIVS  ADDRESS=(414,415,416,417)
   *
   P000009  SLIDLIST  HOSTDRV=D0000090
   *
   D0000090 SLIDRIVS  ADDRESS=(510,511,512,513)
   *
   P000010 SLIDLIST HOSTDRV=D000100
   *
   D000100 SLIDRIVS ADDRESS=(,,,) 
   

   In these macros, you specified the following:

   • The assembler labels of the SLIDLIST macros that define the drive panels are indeed P0000001, P0000002, P0000009, and P0000010 as specified on the SLILSM macro.

   • Each SLIDLIST HOSTDRV parameter specifies the assembler label of the corresponding SLIDRIVS macro.

   • The assembler labels on the SLIDRVS macros match, and the ADDRESS parameters specify the unit addresses of each drive on each panel.

     Note:

     • These are the device addresses you determined in "Planning for Library-Attached Transports."

     • You did not specify drive addresses for panel P000010, so you can add drives there later if necessary.

   Tip: This example shows a single host. For additional information on defining device addresses in a client/server environment, refer to Configuring and Managing SMC.

8. Create the SLIACS macro for ACS01:

   ACS01    SLIACS FUTRLSM=(8500,16),                                   X
            LSM=(LSM0100,LSM0101,LSM0102,LSM0103)
   

   Note:

   Before you configure HSC for the SL8500, verify that all components of the SL8500 are operational. HSC builds its library configuration from the information reported by the library. If SL8500 components are not operational, the library information may not be reported to HSC, and the HSC configuration of the SL8500 is incomplete.

   To verify that all the components of the SL8500 are operational, use the SLConsole (either the panel on the SL8500 or a remote SLConsole). Select Tools, then select System Detail.

   • All SL8500 components should be green. If the components are not green, and you have already configured the SL8500 to HSC, the missing components probably have not been configured.

   • If the drives are red, the drive configuration can be updated dynamically using the SET SLIDRIVS utility (refer to ELS Command, Control Statement, and Utility Reference) and the MODify CONFIG command. If only the drives are red, you can proceed with the HSC configuration.

   • The elevators (Elevator Folder) must be green. If the elevators are not green, do not configure the SL8500 to HSC. The elevators are the logical PTPs. Without PTPs, HSC will not know that the SL8500 rails are connected.

   In this macro, you specified the following:

   • The assembler label is indeed ACS01, as specified in the SLIALIST macro.

   • The FUTRLSM parameter defines four SL8500s that will later be physically added to the configuration. HSC sees each rail in an SL8500 as an entire LSM. An SL8500 library contains four rails (LSMs), thus the lsmnum value must be in multiples of four, so in this example 16 LSMs equals 4 future SL8500s.

   • The LSM parameter specifies the assembler labels of the 4 SLILSM macros for each SL8500 rail (starting with the first).

9. Create the SLILSM macro for the first SL8500 rail/LSM:

   LSM0100  SLILSM PASTHRU=((0,M),(0,M),(0,M)),                           X
                  ADJACNT=(LSM0101,LSM0102,LSM0103),                      X
                  DRIVE=(1),                                              X
                  DRVELST=(P010001),                                      X
                  TYPE=8500,                                              X
                  DOOR=8500-1
   

   In this macro, you specified the following:

   • The assembler label is indeed LSM0100, as specified in the SLIACS macro.

   • The PASTHRU parameter specifies:

     • 0, which is the value for SL8500 internal PTPs (elevators), repeated three times because the SL8500 has 4 LSMs and each LSM needs to pass thru to the other 3 LSMs.

     • M designates this LSM as the master. In an SL8500, the lowest numbered LSM is always the master.

   • The ADJACNT parameter specifies the assembler labels of the other 3 rails (LSMs) in the SL8500.

   • The DRIVE parameter specifies only one transport panel, which is always the case for SL8500 rails/LSMs, and the DRVELST parameter specifies P010001 as the assembler label of the SLID LIST macro that defines the transports in the single drive panel.

   • The LSM type is 8500.

   • DOOR=SL8500-1 means that there is a single SL8500 CAP.

10. Create the SLIDLIST and SLIDRVS macros for the first SL8500 rail/LSM:

    P010001  SLIDLIST HOSTDRV=(D0100010,D0100011)
    *
    D0100010 SLIDRIVS ADDRESS=(,,,9400,,,,9401,,,,,,,,)
    D0100011 SLIDRIVS ADDRESS=(,,,9400,,,,9401,,,,,,,,)
    

    In these macros, you specified the following:

    • The assembler labels of the SLIDLIST macro that defines the single SL8500 drive panel is indeed P010001 as specified on the SLILSM macro.

    • Each SLIDLIST HOSTDRV parameter specifies the assembler label of the corresponding SLIDRIVS macro.

    • The assembler labels on the SLIDRVS macros match, and the ADDRESS parameters specify the unit addresses of each drive on each panel.

      Note:

      • These are the device addresses you determined in "Planning for Library-Attached Transports."

      • This example shows a drive panel for each of the two hosts. For more information on defining device addresses in a client/server environment, refer to Configuring and Managing SMC.

11. Repeat Step 8 through Step 10 for the other 3 SL8500 rails/LSMs.

    The numbers will change but the basic coding does not except that these LSMs, in terms of PTP control, are Slave LSMs, which is always the case with SL8500s.

12. Create the SLIENDGN macro.

Running the SLICREAT Utility To Format the New CDS

After you code the LIBGEN macros as described in "Coding the LIBGEN Macros," assemble and link-edit the LIBGEN macros and run the SLICREAT utility to format the new CDS:

1. Assemble and link–edit the LIBGEN macros.

   The following shows example LIBGEN assembler and linkage editor JCL. Update this example with your LIBGEN macros and run the job.

   //*
   //ASM     EXEC PGM=ASMA90
   //SYSPRINT  DD SYSOUT=*
   //SYSTERM   DD SYSOUT=*  (optional)
   //SYSLIB    DD DSN=SYS1.MACLIB,DISP=SHR
   //          DD DSN=SLS.SLSMAC,DISP=SHR
   //SYSUT1    DD UNIT=SYSDA,SPACE=(CYL,(3,1))
   //SYSLIN    DD DSN=&&OBJ,UNIT=SYSDA,
   //             SPACE=(CYL,(1,1)),DISP=(,PASS)
   //SYSIN     DD *
   
                     LIBGEN deck goes here
   
   /*
   //LKED    EXEC PGM=IEWL,PARM='LIST,XREF,RENT,REUS,REFR,RMODE=24',
   //                            COND=(0,NE)
   //SYSPRINT  DD SYSOUT=*
   //SYSLMOD   DD DSN=SLS.your.hsc.linklib(lgenname),DISP=SHR
   //SYSUT1    DD UNIT=SYSDA,SPACE=(CYL,(3,1))
   //SYSLIN    DD DSN=&&OBJ,DISP=(OLD,DELETE)
   //*
   

2. Run SLICREAT to format the New CDS.

   The following shows example JCL for the SLICREAT program. This sample is also included in the HSC SAMPLIB as member JCLCRT.

   //SLICREAT JOB (account),'programmer',CLASS=A 
   //CREATE   EXEC PGM=SLICREAT,                   CDS CREATE MODULE 
   //             PARM='libgen-load-module-name', 
   //             REGION=6M 
   //*
   //STEPLIB  DD  DSN=your.hsc.linklib,DISP=SHR 
   //SYSPRINT DD  SYSOUT=*                         MESSAGES 
   //*
   //******************************************************************
   //*            LIBRARY PRIMARY CONTROL DATASET (CDS) 
   //******************************************************************
   //SLSCNTL  DD  DSN=SLS.SLSCNTL,                PRIMARY CDS 
   //             SPACE=(4096,s,,CONTIG,ROUND),   REPLACE 's' WITH YOUR
   //             DISP=(NEW,CATLG,DELETE),        SPACE CALCULATIONS 
   //             UNIT=SYSDA 
   //******************************************************************
   //*            LIBRARY SECONDARY CONTROL DATASET (CDS) 
   //******************************************************************
   //SLSCNTL2 DD  DSN=SLS.SLSCNTL2,               SECONDARY CDS 
   //             SPACE=(4096,s,,CONTIG,ROUND),   REPLACE 's' WITH YOUR
   //             DISP=(NEW,CATLG,DELETE),        SPACE CALCULATIONS 
   //             UNIT=SYSDA 
   //******************************************************************
   //*            LIBRARY STANDBY CONTROL DATASET (CDS) 
   //******************************************************************
   //SLSSTBY  DD  DSN=SLS.SLSSTBY,               STANDBY CDS 
   //             SPACE=(4096,s,,CONTIG,ROUND),   REPLACE 's' WITH YOUR
   //             DISP=(NEW,CATLG,DELETE),        SPACE CALCULATIONS
   //             UNIT=SYSDA //******************************************************************
   

   In "CDS DASD Space Requirements," you determined the size of the CDS to support your ELS system.

   Note:

   • For an example of using SLICREAT to format journals, refer to the ELS Legacy Interfaces Reference.

   • Run SLICREAT with the highest level of the software that you are running on any LPAR.

Running the SLUADMIN CDSCREAT Utility to Create the CDS (Tapeless VSM Only)

For only new Tapeless VSM configurations (no RTDs attached, but you can have VLEs attached), run the SLUADMIN CDSCREAT utility to create the CDS as shown in the example below.

//CDSCREAT JOB (account),'programmer',CLASS=A 
//CREATE   EXEC PGM=SLUADMIN,
//             REGION=6M 
//*
//STEPLIB  DD  DSN=your.hsc.linklib,DISP=SHR 
//SYSPRINT DD  SYSOUT=*                         MESSAGES 
//*
//******************************************************************
//*            LIBRARY PRIMARY CONTROL DATASET (CDS) 
//******************************************************************
//SLSCNTL  DD  DSN=SLS.SLSCNTL,                PRIMARY CDS 
//             SPACE=(4096,s,,CONTIG,ROUND),   REPLACE 's' WITH YOUR
//             DISP=(NEW,CATLG,DELETE),        SPACE CALCULATIONS 
//             UNIT=SYSDA 
//******************************************************************
//*            LIBRARY SECONDARY CONTROL DATASET (CDS) 
//******************************************************************
//SLSCNTL2 DD  DSN=SLS.SLSCNTL2,               SECONDARY CDS 
//             SPACE=(4096,s,,CONTIG,ROUND),   REPLACE 's' WITH YOUR
//             DISP=(NEW,CATLG,DELETE),        SPACE CALCULATIONS 
//             UNIT=SYSDA 
//******************************************************************
//*            LIBRARY STANDBY CONTROL DATASET (CDS) 
//******************************************************************
//SLSSTBY  DD  DSN=SLS.SLSSTBY,               STANDBY CDS 
//             SPACE=(4096,s,,CONTIG,ROUND),   REPLACE 's' WITH YOUR
//             DISP=(NEW,CATLG,DELETE),        SPACE CALCULATIONS
//             UNIT=SYSDA 
//******************************************************************
//SLSPRINT DD SYSOUT=*
//SLSIN DD *
CDSCREAT, +
HOSTID=(EC20,EC21), +
COMPRFX=4B, +
TCHNIQE=STANDBY
/* 

Note:

In "CDS DASD Space Requirements," you determined the size of the CDS to support your ELS system.

In this example:

• Hosts EC20 and EC21 are the SMF IDs of the hosts where the subsystem will execute.

• 4B is the hexadecimal representation of the command prefix character ('.')

• STANDBY indicates that three HSC CDS data sets are to be formatted and used by the system.

For details of all SLUADMIN CDSCREAT utility parameters, refer to the ELS Commands, Control Statements, and Utility Reference.

Note:

In a tapeless configuration, you cannot issue commands or use parameters that reference library components.

Defining and Creating CDS Log Files

To define and create CDS log files:

1. Use the FMTLOG utility to pre-format the log files.

   The size of the allocated log files depends on the number of transactions your system generates, as well as the frequency of performing the offload. StorageTek suggests you allocate and activate some test log files and determine the rate at which they fill before determining the size of the production log files.

   Sample JCL:

   //FMTLOG  JOB (account),REGION=1024K
   //S1 EXEC PGM=SLUADMIN,PARM=MIXED
   //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR
   //SLSLOG1 DD DSN=hlq.CDSLOG1,DISP=(,CATLG,DELETE),
   // UNIT=SYSDA,SPACE=(CYL,100)
   //SLSLOG2 DD DSN=hlq.CDSLOG2,DISP=(,CATLG,DELETE),
   // UNIT=SYSDA,SPACE=(CYL,100)
   //SLSPRINT DD SYSOUT=*
   //SLSIN DD *
   FMTLOG
   /* 
   

   Note:

   Data sets must be cataloged, so that they can be located by dynamic allocation. You can assign either one or two log files. If you assign two log files, the second is a copy of the first. There is no ”automatic switching” between log files. If an error occurs on a file, it is disabled and logging continues on the other file.

2. Use the SET LOGFILE utility to activate the log files.

   Sample JCL:

   //SETLOG  JOB (account),REGION=1024K
   //S1 EXEC PGM=SLUADMIN,PARM=MIXED
   //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR
   //SLSPRINT DD SYSOUT=*
   //SLSIN DD *
   SET LOGFILE(hlq.CDSLOG1,hlq.CDSLOG2)
   /*
   

Running Multiple HSC Tapeplexes on One LPAR (MULT Mode)

ELS now supports the ability to run multiple instances of HSC on the same LPAR. The following restrictions apply when HSC is started in MULT mode:

• If any HSC on the LPAR specifies the MULT parameter, then all HSC subsystems on that LPAR must specify the MULT parameter.

• Two HSC subsystems on the same LPAR must represent separate tapeplexes, that is, each HSC must point to a different set of CDSs.

• ExPR started task is not supported on any LPAR where HSC is running in MULT mode.

• A new parameter, SSYS, is required on any SLUADMIN step running on an LPAR where HSC is in MULT mode.

• The SLIEXERS installation utility cannot be run on an LPAR where HSC is in MULT mode.

• Any application using the HSC Significant Event Notification (SEN) facility on an LPAR where HSC is running in MULT mode must be modified to pass a subsystem name parameter. Refer to the ELS Programming Reference for more detail on the SEN facility.

The following are recommendations for running multiple HSCs on one LPAR:

• Each HSC subsystem should specify a unique command prefix.

• Each HSC subsystem should specify MSGPRFX(YES) in its EXECPARM parameter. Using this parameter, along with a unique command prefix, identifies the HSC subsystem source for HSC console EXEC JCL parameters. Using this parameter, along with a unique command prefix, identifies the HSC subsystem source for HSC console messages.

• Each HSC subsystem should use a unique SMF record ID. This allows statistics to be collected for individual HSC subsystems.

• Each HSC subsystem should use a unique ENQUEUE name. This can be done by using the SLUADMIN SET MAJNAME utility. Specifying the same enqueue name for multiple CDSs can lead to performance issues.

• MULT mode and VTCS Coupling Facility:

  • If the VTCS Coupling Facility is used, StorageTek recommends that it should be used only on one HSC/VTCS system on an LPAR.

  • If the VTCS Coupling Facility is used on more than one HSC/VTCS subsystems within a single Sysplex, each system MUST specify a unique LOCKSTR value. Refer to the ELS Command, Control Statement, and Utility Reference for more information on the VTCS CONFIG utility.

Defining Volumes to ELS

With ELS 7.3 and above, you now use the HSC POOLPARM and VOLPARM statements to define all volumes and their pools, native Library Volumes, cleaning cartridges, MVCs, VTVs, and the HSC SET VOLPARM utility to load them. For more information, refer to the ELS Command, Control Statement, and Utility Reference.

Tip: Do you want to switch to POOLPARM/VOLPARM way but do not know how to do the conversion? The VOLPCONV utility helps to convert existing VOLDEF, SCRPDEF, MVCDEF, CONFIG VTVVOL, and CONFIG MVCVOL statements to SET VOLPARM statements. For more information, refer to the ELS Command, Control Statement, and Utility Reference.

In the following sections, you use the same basic procedure, with variations for the type of volume and its pool. But first, a discussion of the benefits of converting to POOLPARM/VOLPARM and some warnings about their use.

Why Should You Use POOLPARM/VOLPARM?

POOLPARM/VOLPARM provides the following advantages over the legacy method of defining volumes:

• Reduce system outages.

  Using POOLPARM/VOLPARM allows you to dynamically delete VTV or MVC ranges from the CDS, without requiring a CDS MERGE process. Deleting VTV or MVC ranges dynamically requires CDS level G or above (CDSLEVEL=V62ABOVE) and also requires that none of the volumes in the deleted range be currently in use.

• Simplify maintenance of volume parameters.

  • All POOLPARM/VOLPARM parameters are maintained in the CDS.

  • Edits ensure that all volsers in your environment are defined only once and belong to only one pool.

  • Current contents of POOLPARM/VOLPARM is available by running the LIBGEN utility (refer to the ELS Command, Control Statement, and Utility Reference for details)

  • When the SET VOLPARM utility is run with APPLY=YES, all updates occur immediately on all hosts.

• Improved management of scratch subpool allocation.

  • POOLPARM/VOLPARM allows only non-subpool scratch volumes to be selected when no scratch subpool is specified. Non-subpool scratch volumes are those volumes defined before any pool definition.

  • Using POOLPARM/VOLPARM rejects mount requests for undefined subpool names from SMC.

  • POOLPARM/VOLPARM provides the ability to limit access to scratch subpools based on client host ID in a client/server environment.

• Improved reporting.

  • Your VOLRPT will automatically pick up subpool definitions, flag MVCs, and show volumes in DR test scratch subpools, as well as flagging undefined volumes.

  • HSC D VOLUME DETAIL shows pool residency.

• Pre-validation.

  • You can use the SLUADMIN utility to pre-validate your POOLPARM/VOLPARM statements before activating them.

  • You can use the SMC POLICY VALIDATE in the SMC subsystem or SMCUSIM utility to ensure that all SMC POLICY statements specify valid subpools.

• POOLPARM/VOLPARM supports volume segregation in the Concurrent Disaster Recovery Test utility.

  • Using POOLPARM/VOLPARM automatically segregates DR test scratch subpools and MVC pools from production. When POOLPARM/VOLPARM is in effect, DR test systems can use only volumes defined in DRTEST pools.

  • In a DR test environment, you can scratch volumes defined as part of DRTEST scratch subpools.

• Using POOLPARM/VOLPARM supports volume segregation in a Cross TapePlex Replication environment.

  • Defining POOLPARM with TYPE=EXTERNAL and OWNRPLEX name ensures that the receiving TapePlex cannot use a VTV as scratch and can receive a VTV only from the specified OWNRPLEX

  • Changing a POOLPARM from TYPE=EXTERNAL to TYPE=SCRATCH allows the receiving TapePlex to scratch VTVs received from another TapePlex in case of an actual disaster.

• A utility is provided to assist in converting existing volume definitions to POOLPARM (for more information, refer to the ELS Command, Control Statement, and Utility Reference).

  • Input includes existing VOLDEF, SCRPDEF, MVCPOOL, and VTCS CONFIG definitions

  • Note that the conversion utility cannot convert "wildcard" characters in VOLATTR statements. You must manually convert wildcard specifications to volume ranges.

Some Things to Consider with POOLPARM/VOLPARM

A few things to remember when using POOLPARM/VOLPARM:

• VTCS CONFIG MVCVOL and VTVVOL definitions are no longer honored.

• HSC control commands SCRPDEF, VOLDEF and MVCDEF are no longer honored.

• Your pool definitions are the same on all hosts. You can, however, use the HOSTID parameter to limit access to scratch subpools.

• Mounts for invalid subpools will be rejected.

• Mounts with no specified subpool can be satisfied only by non-subpool volumes.

• You can disable POOLPARM/VOLPARM by running the SET VOLPARM utility with an empty SLSPARM input file. Once POOLPARM/VOLPARM is disabled, the previous version of POOLPARM/VOLPARM remains in effect for MVC and VTV definitions until you run VTCS CONFIG, and the previous POOLPARM/VOLPARM POOL definitions remain in effect until you run the VOLDEF, SCRPDEF and MVCDEF commands on the HSC host(s).�

• If you run CDRT with POOLPARM/VOLPARM in effect you must have DRTEST pools defined or scratch mounts will not be satisfied, and no MVCs can be used.

• SET VOLPARM execution time increases exponentially as more volume ranges are added. To facilitate efficient processing of VOLPARM statements, combine volume ranges.

  For example, the following ranges can be combined into one VOLPARM statement using the SET VOLPARM JOIN utility.

  VOLPARM VOLSER(A00000-A00999) MED(VIRTUAL) RECT(VIRTUAL)
  VOLPARM VOLSER(A01000-A01999) MED(VIRTUAL) RECT(VIRTUAL)
  VOLPARM VOLSER(A02000-A02999) MED(VIRTUAL) RECT(VIRTUAL)
  

  For more information on the SET VOLPARM JOIN utility, refer to the ELS Command, Control Statement, and Utility Reference.

Defining Library Volumes

To define Library Volumes:

1. Create a POOLPARM statement to define volume scratch pools.

   For example, to define a scratch pool for use by hosts MVS1 and MVS2:

   POOLPARM NAME(SYS19840P1)TYPE(SCRATCH)HOSTID(MVS1,MVS2)LABEL(SL)
   

2. Create a VOLPARM statement to define the volumes.

   For example, to define a range of 9840C volumes:

   VOLPARM VOLSER(C1000-C1999)MEDIA(STK1R)RECTECH(STK1RC)
   

3. Ensure that you define sufficient cleaning cartridges.

   Go to "Defining Cleaning Cartridges."

   Note:

   Once you install higher density (or encryption-capable) drives for existing media, note that if you eject and re-enter an existing cartridge, HSC sets the density to "unknown" whenever the ACS contains drives other than the lowest density for the media, and sets the encryption status to "unknown" whenever the ACS contains encrypting drives for the media. This means that in the allocation process, SMC attempts to allocate the specific volume to the highest density drives and to encrypting drives, whenever the volume is flagged as "unknown."

   To manage this situation, do one of the following:

   • You can use VOLPARMs for the volume to indicate its actual density (encryption status), and then, once it is scratched, reset the VOLPARM to the desired recording technique.

   • You can use the vaulted volume feature to manage the ejected cartridge as a non-library volume, using LCM. When you use this feature, the HSC CDS records the recording technique at the time of the eject and restores it at the time of the enter.

Defining Cleaning Cartridges

To define cleaning cartridges:

1. Create a POOLPARM statement to define the cleaning cartridge pool.

   For example, to define the 9840 cleaning cartridge Pool with cleaning parameters:

   POOLPARM TYPE(CLEAN)MAXCLEAN(25)
   

2. Create a VOLPARM statement to define the cleaning cartridges.

   For example, to define a range of 9840 cleaning cartridges:

   VOLPARM VOLSER(CLN300-CLN310)MEDIA(STK1U)
   

3. Do you need to define MVCs?

   If so, go to "Defining MVCs." Otherwise, go to "Validating and Applying the Volume Definitions."

Defining MVCs

Note:

POOLPARM/VOLPARM is the preferred method for defining MVCs for ELS 7.3 but you can still use CONFIG to define MVCs. For more information, refer to the ELS Legacy Interfaces Reference. Also note that if you have existing volsers defined using CONFIG, you must run DECOMP against your CONFIG deck, remove the CONFIG definitions, and rerun CONFIG before you create POOLPARM/VOLPARM definitions.

To define MVCs:

1. Create a POOLPARM statement to define the MVC pool.

   For example, to define the T10000 MVC Pool with reclaim parameters:

   POOLPARM NAME(SYS1MVCT1)TYPE(MVC)MVCFREE(40) MAXMVC(4) THRESH(60) START(70)
   

2. Create a VOLPARM statement to define the MVCs.�

   For example, to define a range of T10000 Full volumes to be encrypted:

   VOLPARM VOLSER(T2000-T2999)MEDIA(T10000T1)RECTECH(T1AE)
   

3. Define VTVs.

   See "Defining VTVs."

Defining VTVs

Note:

POOLPARM/VOLPARM is the preferred method for defining VTVs for ELS 7.3 but you can still use CONFIG to define MVCs. For more information, refer to the ELS Legacy Interfaces Reference. Also note that if you have existing volsers defined using CONFIG, you must run DECOMP against your CONFIG deck, remove the CONFIG definitions, and rerun CONFIG before you create POOLPARM/VOLPARM definitions.

To define VTVs:

1. Create a POOLPARM statement to define the volume scratch pool.

   For example, to define a VTV scratch pool for use by hosts MVS1 and MVS2:

   POOLPARM NAME(SYS1VTV1)TYPE(SCRATCH)HOSTID(MVS1,MVS2)LABEL(SL)
   

2. Create a VOLPARM statement to define the VTVs.

   For example, to define a range of VTVs initialized as scratch:

   VOLPARM VOLSER(V5000-V5999)MEDIA(VIRTUAL)INITSCR
   

Validating and Applying the Volume Definitions

1. 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 2. Otherwise, rework your volume definitions, then go to Step 2.

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

   SET VOLPARM APPLY(YES)
   

3. Physically enter the cartridges into the ACS.

   For more information, refer to Managing HSC and VTCS.

Adding Definitions for ACF/VTAM Communications

To optimize performance, Oracle recommends that you set the HSC COMMPath METHod parameter to TCP, which does not place a performance burden on HSC, as shown in the example in "Creating the HSC PARMLIB Member."

If you set the HSC COMMPath METHod to TCP, then specify the SYSTCPD DD statement in your HSC START procedure to define TCP/IP options for the HSC job, as shown in the example in "Sample HSC Startup Procedure". The SYSTCPD DD statement identifies the data set used to obtain parameters defined by the IBM TCPIP.DATA configuration data set. Refer to the IBM TCP/IP Customization and Administration Guide for more information.

An alternative to setting the HSC COMMPath METHod to TCP is to set the HSC COMMPath METHod to VTAM. VTAM is another HSC host-to-host communications method that does not place a performance burden on HSC.

If you set COMMPath METHod to VTAM, you must define the following to VTAM:

• APPL

• CDRSC

• CDRM (if not using existing CDRMs)

• LOGMODE table entry for SNASVCMG (contained in the IBM-supplied logon mode table).

• LOGMODE table entry for SLSSVCMG. This can be defined the same as SNASVCMG. If not defined, the default logmode entry is used.

A sample APPL statement is contained in the HSC SAMPLIB member HSCAPPL, shown below, with the HSC application program minor node (APPLID) as APHSC1:

HSCAPPL  VBUILD TYPE=APPL
APHSC1   APPL  APPC=YES,
               AUTOSES=1,                                           +
               DMINWNL=1,                                           +
               DMINWNR=1,                                           +
               DESESLIM=2,                                          +
               EAS=10

where:

APPC=YES

must be coded because HSC uses VTAM LU 6.2 services.

AUTOSES=1

defines the number of contention-winner sessions VTAM is to establish automatically with the first CNOS request.

DMINWNL=1

defines the minimum number of parallel sessions with the local LU as the contention-winner. HSC only requires and uses one local contention-winner session.

DMINWNR=1

defines the minimum number of parallel sessions with the remote LU as the contention-winner. HSC only requires and uses one remote contention-winner session.

DSESLIM=2

defines the maximum number of sessions allowed between the local LU and a remote LU. This should be 2 because the HSC only establishes two sessions between each HSC: one local contention-winner session and one remote contention-winner session.

EAS=10

sets an estimated number of concurrent sessions this APPLID will have with other LUs. Refer to the IBM ACF/VTAM manuals for definitions and explanations.

Defining the SYS1.PARMLIB Member SMFPRMxx

HSC can produce SMF record subtypes for HSC and VTCS events. To produce these record subtypes, you must add two statements to your SMF parameters in SYS1.PARMLIB member SMFPRMxx to specify the following:

• HSC subsystem for which records are produced

• Recording interval in seconds

• SMF record subtypes. The record subtypes must be specified as a list (subtype1, subtype2,...subtypen), as a range (subtype1-subtypen), or as a combination (subtype1, subtype2-subtypen). A range must be specified using a dash; a colon is invalid for a range.

  Note:

  The TYPE parameter in the SMFPRMxx member must match the SLILIBRY SMF= parameter specified in "Coding the LIBGEN Macros."

Tip: Oracle recommends that you specify that your system produces the HSC SMF record subtypes 1 through 8 and 10, 11, 13 through 21, and 25 through 33 as shown in the following example. For more information on SMF record layouts, refer to the ELS Programming Reference.

The following shows sample statements that produce record subtypes 1 through 8 and 10, 11, 13 through 21, and 25 through 33 at 15 minute intervals for HSC subsystem SLS0.

SUBSYS(SLS0,INTERVAL(001500),TYPE(255))
SUBPARM(SLS0(SUBTYPE, (1-8,10,11,13-21,25-33)))

Creating the HSC PARMLIB Member

The HSC PARMLIB member is where you specify any commands that you want executed at HSC startup as shown in the example that follows.

CDSDEF DSN1(HSC1.PRIM),DSN2(HSC1.BKUP),DSN3(HSC1.STDBY)
MGMTDEF DSN(HSC.PARMS)
COMMPATH HOSTID(HST1) TCPPATH(HST1NAME METHOD(TCP)
COMMPATH HOSTID(HST2) TCPPATH(HST2NAME METHOD(TCP)
CAPP 9,01:00:00,AUTO
MNTD AUTOCLN(ON)EJCTAUTO(ON)

In this example:

CDSDEF

The CDSDEF control statement in the HSC PARMLIB determines how many CDS copies are allocated by the HSC.These definitions are invoked at HSC initialization and remain set until HSC termination. The definitions cannot be altered without HSC shutdown and restart.

Caution:

The number of CDS copies implied by the TCHNIQE parameter must be the same as the number of CDS copies implied by the CDSDEF control statement otherwise the HSC will not initialize.

• If the number of CDS copies defined on the CDSDEF control statement is more than are specified by the TCHNIQE parameter, do the following:

  Stop the HSC on all hosts.

  Run a SLUADMIN SET TCHNIQUE to increase the number of copies to match the number implied by the CDSDEF control statement.

  Restart HSC.

• If the number of CDS copies defined on the CDSDEF control statement is less than are specified by the TCHNIQE parameter, do the following:

  Stop the HSC on all hosts.

  Run a SLUADMIN SET TCHNIQUE to decrease the number of copies to match the number implied by the CDSDEF control statement.

  Restart HSC.

The control data set names are recorded in the Database Heartbeat (DHB) record. During HSC initialization, the data set names in the DHB are compared with the data set names specified on the CDSDEF control statement in the HSC PARMLIB.

If a data set name specified on the CDSDEF statement does not match any of the control data set names recorded in the DHB, that control data set is disabled. If all the specified control data sets are disabled, the HSC will not initialize. The specific assignment of enabled control data sets to the primary, secondary, and standby control data set(s) is made based on the control data set assignments recorded in the Database Heartbeat record.

HSC.PARMS

is the data set that contains your system's MGMTclas and STORclas statements.

COMMPATH HOSTID(HST1) TCPPATH(HST1NAME) METHOD(TCP)
COMMPATH HOSTID(HST2) TCPPATH(HST2NAME) METHOD(TCP)

specifies that TCP is the host-to-host communications method between HSC hosts HST1 and HST2. Oracle recommends that you specify TCP to allow even sharing of resources in a multi-host environment

CAPP 9,01:00:00,AUTO

specifies CAP preferences.

MNTD AUTOCLN(ON) EJCTAUTO(ON)

specifies automatic drive cleaning and automatic ejection of spent cleaning cartridges.

EXECPARM Statement

The EXECPARM statement provides an alternative method of specifying GTF Eid and Fid parameters.

Syntax

Figure 4-1 EXECPARM Statement

Parameters

MSGPRFX

optionally, specifies control of whether the command prefix is to precede WTO or WTOR messages to the operator.

Yes

indicates that the command prefix is to display preceding WTO or WTOR messages to the operator.

No

indicates that the command prefix is not to display preceding WTO or WTOR messages to the operator.

Eid

optionally, gtfeid specifies a GTF event ID.

PARM='Eid(user­specified­event­id)' parameter is valid for use in the HSC initialization procedure as an alternative method of specifying the GTF event ID.

Fid

optionally, gtffid specifies a GTF format ID.

PARM='Fid(user­specified­format­id)' parameter is valid for use in the HSC initialization procedure as an alternative method of specifying the GTF format ID.

HOSTID

optionally, host­id specifies the system ID associated with the request to process the EXECParm control statement.

Note:

If the hostid specified does not match the host executing the command, the command is ignored and no message is issued.

Defining Command Authority

If HSC user exit SLSUX15 sets a return code of UX15CHKA, the exit issues a command authorization request to the system security product. The following shows an example of RACF profile and permissions commands to give user SAM15 update access to all HSC/VTCS commands and user JOE13 query access to all HSC/VTCS commands. Note that you can no longer specify the .VT prefix for VTCS commands, which is no longer passed to SLSUX15. Refer to the ELS Programming Reference for a sample of how to define command security based on the originating host ID of the command.

********************************************************************************
* Define a profile in the OPERCMDS class for all HSC and VTCS commands *
********************************************************************************
RDEFINE OPERCMDS subsysname.* UACC (NONE)
********************************************************************************
************ Allow user JOE13 access to all query HSC/VTCS commands
********************************************************************************
**********PERMIT subsysname.command CLASS(OPERCMDS) ID(JOE13) ACCESS (QUERY)
********************************************************************************
************ Allow user SAM15 update access to all HSC/VTCS commands
********************************************************************************
**********PERMIT subsysname.command CLASS(OPERCMDS) ID(SAM15) ACCESS (UPDATE)
********************************************************************************

Updating HSM

HSM users that have mixed devices that were "logically" defined as the same type of device, such as 3490E but are "physically" different, such as T9940, virtual (VTD), or 9490 must set the following parameter in HSM:

SETSYS RECYCLEINPUTDEALLOCFREQUENCY(MIGRATION(1))

By setting this parameter, when HSM is "recycling," it will deallocate the input drive after it processes each input tape. This is required where the tapes being recycled are "physically" mixed as described above.

If you do not set this parameter, it is possible that you could allocate a 9490 transport for the first tape, then if the second tape was virtual (VTV) or STK2P, the job would fail due to media incompatibility. That is, you could not physically mount the second tape (virtual or STK2P media) on the 9490 drive that had been allocated for the first tape.

Creating and Cataloging the HSC Startup Procedure

You start HSC by entering the MVS START command that invokes the HSC startup procedure, which resides in the cataloged procedure library of the host system. For more information, see:

• "Running Multiple HSC Tapeplexes on One LPAR (MULT Mode)"

• "EXEC Statement"

• "Sample HSC Startup Procedure"

• "EXECPARM Statement" for an alternative method of specifying GTF Eid and Fid parameters.

  Note:

  If you previously controlled which hosts started VTCS by referencing or not referencing the VTCS software in your JCL concatenation, this capability is provided in ELS by using the NOVTCS parameter on the HSC startup PARM. For more information, see "EXEC Statement."

Running Multiple HSC Tapeplexes on One LPAR (MULT Mode)

ELS supports the ability to run multiple instances of HSC on the same LPAR. The following restrictions apply when HSC is started in MULT mode:

• If any HSC on the LPAR specifies the MULT parameter, then all HSC subsystems on that LPAR must specify the MULT parameter.

• Two HSC subsystems on the same LPAR must represent separate tapeplexes, that is, each HSC must point to a different set of CDSs.

• The ExPR started task is not supported on any LPAR where HSC is running in MULT mode.

• A new parameter, SSYS, is required on any SLUADMIN step running on an LPAR where HSC is in MULT mode.

• The SLIEXERS installation utility cannot be run on an LPAR where HSC is in MULT mode.

• Any application using the HSC Significant Event Notification (SEN) facility on an LPAR where HSC is running in MULT mode must be modified to pass a subsystem name parameter. Refer to the ELS Programming Reference for more detail on the SEN facility.

The following are recommendations for running multiple HSCs on one LPAR:

• Each HSC subsystem should specify a unique command prefix.

• Each HSC subsystem should specify MSGPRFX(YES) in its EXECPARM or EXEC JCL parameters. Using this parameter, along with a unique command prefix, identifies the HSC subsystem source for HSC console EXEC JCL parameters. Using this parameter, along with a unique command prefix, identifies the HSC subsystem source for HSC console messages.

• Each HSC subsystem should use a unique SMF record ID. This allows statistics to be collected for individual HSC subsystems.

• Each HSC subsystem should use a unique ENQUEUE name. This can be done by using the SLUADMIN SET MAJNAME utility. Specifying the same enqueue name for multiple CDSs can lead to performance issues.

• MULT mode and VTCS Coupling Facility.

  • If the VTCS Coupling Facility is used, Sun StorageTek recommends that it should be used only on one HSC/VTCS system on an LPAR.

  • If the VTCS Coupling Facility is used on more than one HSC/VTCS subsystems within a single Sysplex, each system must specify a unique LOCKSTR value. Refer to the ELS Command, Control Statement, and Utility Reference for more information on the VTCS CONFIG utility.

EXEC Statement

The EXEC statement specifies HSC startup options.

Syntax

Figure 4-2 EXEC Statement

Parameters

PARM=

defines the list of parameters passed to the HSC initialization routine.

Note:

If you enter more than one of the following parameters, you must separate them with a blank space (e.g., BASE SSYS(subsystem) RESET).

BASE

specifies that the HSC initialize and execute at the base service level.

SSYS

specifies that HSC initialization search for the subsystem name specified. If the name is not found or is not a valid name, the subsystem terminates. subsystem must be a 1­ to 4­character name or problems can occur when initializing the HSC.

This parameter permits you to symbolically specify the subsystem and retain the same startup procedure whether starting the HSC before or after JES.

INIT

specifies that only preinitialization of the HSC occurs.

Note:

If PARM=INIT is specified, the HSC subsystem is only initialized. It is still necessary to issue a HSC Start command to start the HSC. If any other parameters are specified with INIT (except for SSYS), they are ignored.

COLD

specifies that any permanent in­memory data structures previously allocated by HSC are reallocated and reinitialized.

On the first startup of the HSC after an IPL, this option is meaningless. If the HSC has been brought up previously for this IPL, use of this option results in the loss of a system linkage index for Program Call (PC) instructions. There are a limited number of system linkage indexes. Once exhausted, they can only be restored by IPLing. If COLD is not specified, the linkage index used previously by the HSC is reused.

This parameter should be used only when absolutely necessary. (The installation instructions for some HSC maintenance may direct you to perform a COLD start.)

Note:

You do not need to include the COLD parameter when you are initializing a HSC that is at a different release level than the HSC that was previously running on a host. When an initializing HSC detects a release level difference, it performs an automatic internal cold start.

RESET

specifies that all subsystem status flags in the MVS Subsystem Communications Vector Table (SSCVT) for the HSC are unconditionally reset. Use of this option may correct a situation in which the HSC was terminated abnormally without resetting the status flags; for example, if the HSC was terminated with the MVS FORCE command.

These messages are possible symptoms of this situation at HSC startup, when a display of active jobs indicates that the subsystem is not active:

• ... ACS subsystem CCCC is ACTIVE

  or

• ... ACS subsystem CCCC is TERMINATING

  or

• ... ACS subsystem CCCC is INITIALIZING

This parameter should only be used in extreme situations and may not correct all error conditions. Contact Oracle Software Support before using this parameter.

Eid

xxxx is 1 to 4 hex characters specifying the GTF event ID used for the duration of this subsystem. "E" is the abbreviation for this parameter. The default Eid value is E086.

Fid

xx is 1 to 2 hex characters specifying the GTF format ID used for the duration of this subsystem. "F" is the abbreviation for this parameter. The default Fid value is 17.

Note:

See "EXECPARM Statement" for an alternate method of specifying GTF, EID, and FID parameters.

Member

For MVS, xx is the suffix of the SLSSYSxx member in SYS1.PARMLIB, or an SLSSYSxx DD statement in the startup procedure used as the automatic commands (PARMLIB control statements) data set. "M" is the abbreviation for this parameter.

Dialog

specifies that messages can be displayed on the operator console and/or written to the system log. This option can be used to further restrict where messages are displayed based on the ROUTCDE. These messages indicate that the HSC is waiting for an active task to complete before the HSC terminates.

For more information on Dialog, see ”OPTION Command and Control Statement” in the ELS Command, Control Statement, and Utility Reference.

If Dialog is specified, one of the options must be selected. There is no default. The options for Dialog include:

Off

specifies that you do not want active task termination messages displayed on the operator console or written to the system log.

Both

specifies that messages are displayed on the operator console and written to the system log.

Console

specifies that messages are displayed on the operator console only.

Log

specifies that messages are written to the system log only.

NOVTCS

specifies that VTCS should not initialize on a host even though VTCS data is present in the CDS.

MULT

Optionally, specifies that multiple HSCs can be run on the same LPAR. Note that if one HSC on an LPAR specifies the MULT parameter, all HSCs running on that LPAR must specify the MULT parameter. See "Running Multiple HSC Tapeplexes on One LPAR (MULT Mode)" for a list of restrictions when using this parameter.

Sample HSC Startup Procedure

The following shows HSC SAMPLIB member JCLPROC, which is a sample HSC startup procedure.

//SLS0     PROC PROG=SLSBINIT,PRM=' ’ 
//* 
//IEFPROC  EXEC PGM=&PROG,TIME=1440, 
//  PARM='&PRM E(E086) F(23) M(00) SSYS(SLS0)',REGION=6M 
//* 
//STEPLIB  DD DSN=SEA700.SEALINK,DISP=SHR 
//* 
//SLSSYS00 DD DSN=SLS.PARMS,DISP=SHR 
//SYSTCPD DD DSN=ddd.eee.fff(anyname)   /* Optional TCPIP parameters) */

In this example:

• In the example PROC shown above, SLS0 is used as both the name of the startup procedure (line 1) and as the subsystem name defined in the SSYS parameter "SSYS(SLS0)" in line 4. This is just an example, you can code any values that work for your site but note the following:

  • HSC subsystem names must be 4 characters in length and must be defined in your IEFSSNxx member.

  • If the startup procedure name and the subsystem name are identical, the SSYS parameter is not required in the startup procedure. If the startup procedure name is not identical to the subsystem name, then the SSYS parameter must point the startup procedure to the required HSC subsystem.

  • TIME=1440 or TIME=NOLIMIT must be specified to ensure that HSC does not time out and terminate.

  • Oracle recommends that you run HSC/VTCS with a region size of at least 6 MB except if you are running utilities or commands that manipulate manifest files, in which case you need the maximum region size your system will allow.

DD Statements for the HSC Startup Procedure

SLSSYSxx

statement that defines the data set containing the HSC PARMLIB. In the example procedure above, xx is replaced by the suffix "00". The SLSSYS00 DD statement matches the M(00) declaration and points to the PARMLIB member "00" that contains your start-up parameters.

SLSUEXIT

statement that defines the data set containing HSC user exits.

Specifying TCPIP Options

The SYSTCPD DD statement can be used to specify TCP/IP options for the HSC job.

This DD statement identifies the data set used to obtain parameters defined by the IBM TCPIP.DATA configuration data set. Refer to the IBM TCP/IP Customization and Administration Guide for more information.

Performance Considerations

This section describes performance considerations.

Define Dispatching Priority for ELS Software

Depending on your requirements, set these software components so the amount of resources available to them is as follows:

• HSC/VTCS — greater than batch and any started task or application requiring quick access to tape but less than an online system

• SMC/HTTP server— greater than the HSC, or if the HSC is inactive, greater than batch and any started task or application requiring quick access to tape but less than an online system

Your requirements may dictate that these products be given access to greater or lesser resources than Oracle recommends here, but you must determine this for your environment. The information above is meant only to serve as a guideline.

During initialization, the HSC uses SYSEVENT TRANSWAP to make its address space non­swappable. The HSC address space cannot be swapped out once this has been accomplished.

Reduce Pass­Thrus

The number of pass­thrus required to mount, dismount, and replace cartridges in LSMs can impact library performance. In a large or busy ACS, this impact may be significant especially during periods of heavy mount activity. There are three types of pass­thrus:

• unavoidable

• unnecessary

• scheduled.

Unavoidable Pass­Thrus

The HSC attempts to minimize the number of pass­thrus required; however, depending upon available tape transports and locations of cartridges, pass­thrus often cannot be avoided. By running Activities Reports on a regular basis and examining the results, you can see that mounts for different LSMs take longer than mounts for the same LSM.

Unnecessary Pass­Thrus

Scratch mounts, dismounts, enters, and ejects that require pass­thrus are unnecessary and should be avoided. These types of activities divert the robotics from productive work especially during periods of peak activity.

If scratch subpools are properly defined and managed, scratch cartridges normally are not involved in pass­thrus. Scratch mounts are the same as specific mounts as far as pass­thrus that cannot be avoided.

The effect of unnecessary pass­thrus is not obvious in the Activities Report. You must compare their number with average mount times to see the effect on performance.

Scheduled Pass­Thrus

Using the Scratch Redistribution utility to balance scratch cartridges involves moving cartridges to various LSMs to achieve scratch balancing. This type of activity involves heavy pass­thru usage. If you must balance scratch volumes across your library, schedule such activity during off peak hours. This approach will make sure that the pass­thru activity involved does not directly interfere with mounts and dismounts for high­priority production.

You can use LCM to schedule pass­thrus. Refer to the LCM User's Guide for more information.

Methods to Reduce Pass­Thru Activity

There are various methods to reduce pass­thru activity:

Set MNTD Float to ON

The Float option of the MNTD command specifies whether the HSC is to select a new home cell location when it dismounts a volume that requires a pass­thru when it is dismounted.

When MNTD Float is set to ON, cartridges are not passed back to their original LSM. The cartridges are assigned new cells in the LSM where they are dismounted. This action eliminates most unnecessary pass­thrus.

Provide adequate free cells

Setting MNTD Float to ON can be overridden if there are no free cells in the dismounting LSM. Dismounted cartridges are passed to other LSMs to find a new home cell.

Use the Display Lsm command to determine the number of free cells in each LSM. Use MOVe or EJect to create free cells if they are needed.

Eject through the CAP closest to the cartridge

If you eject a cartridge through the CAP of the LSM where it resides, no pass­thrus are required.

If you eject a cartridge without specifying a CAPid, the cartridge is ejected through the highest priority CAP that is not busy. This type of activity may cause one or more unnecessary, nonproductive pass­thrus.

The recommended way to accomplish ejects without affecting performance with pass­thrus, is to use multiple CAP option on the EJECt utility. By specifying multiple CAPs (i.e., CAP(00:00:00,00:00:01,00:00:02)), the desired effect (i.e., no pass­thrus) is achieved.

Redistribute cartridges during off­peak times

You can use the MOVe command and utility to move cartridges within an LSM or between LSMs. The Scratch Redistribution utility can be used to move scratch cartridges between LSMs until an equilibrium is reached. Each inter­LSM movement of cartridges causes pass­thrus which delay robot movement in mounting a cartridge.

Depending on the number of cartridges to be redistributed, you may prefer to schedule moves and scratch redistribution during periods of low data center activity. The redistribution runs faster and performance is not affected during off peak times.

Reduce Operator Intervention

Although the ACS runs mostly unattended, situations occur where operator intervention is required. Excessive and unnecessary operator intervention impacts library performance. There are specific ways in which operator intervention can be reduced. These include:

Set SMC ALLOCDef DEFer(ON)

If a keep is issued for a cartridge while it is being mounted, the HSC issues a message indicating that the robot cannot dismount the volume. An operator must unload the tape transport and then reply "R" to the message.

This situation is caused by programs allocating cartridges through JCL, not opening the data set on the cartridge, and terminating before the mount completes. It causes unnecessary mounts, extends dismount time, and delays the availability of cartridges and transports.

If a message requiring operator intervention occurs frequently, you may want to set ALLOCDef DEFer(ON) so ACS mounts are deferred until the data set is opened. Alternatively, you can code User Exit 09 for JES2 or User Exit 11 for JES3 with SETUP processing to selectively defer a subset of ACS mounts.

Set CAP Preference

In a multiple­LSM ACS, the CAPPref command establishes an ordered list of CAPs to use should the operator or HSC start an activity that requires a CAP without specifying a CAPid.

To enter or eject cartridges faster, set CAPPref such that the CAP closest to the cartridge racks is preferred. This minimizes operator travel distance.

In large ACS configurations, of five or more LSMs, consider setting CAPPref such that a CAP in the middle of the ACS has the highest priority. This may make the operators walk further but it reduces the number of pass­thrus should the default (highest priority) CAPid be used for ejecting cartridges.

Prefetch Enters

Nonlibrary cartridges that are mounted on library transports are delayed while the operator fetches and enters them. This is a common occurrence for HSC sites with all transports attached to the library.

If you or your scheduling system can predict which nonlibrary cartridges will be mounted in the library before a mount message appears, your operator can improve performance by entering those cartridges in advance.

Avoid Crashing Test Systems

Library attached hosts own library resources, including CAPs, tape drives, and cartridges. If a host fails, another host must clean up the resources held by the failing host. This delays mounts and dismounts on the recovering host while recovery takes place.

You should attempt to shut down the HSC properly before IPLing a system. This is especially important for test systems that may be restarted several times a day.

Use Unit Affinity Separation

Unit affinity separation can improve library performance by eliminating the need for operators to enter or eject tape cartridges when volumes are requested with unit affinity. Without unit affinity separation, a tape transport is selected based on the location of the first volume.

Refer to the SMC Configuration and Administration Guide for information about the ALLOCDef command SEPLvl parameter, which specifies the exclusion level at which affinity chains are separated.

Reduce Tape Transport Contention

Balanced use of library tape transports results in better robotic and system performance. In a multiple LSM library, you want the workload to be spread evenly among the robots rather than overloading one robot while the others are idle. Within each LSM, you want mounts to be evenly distributed among transports rather than having the robot wait for a cartridge to be rewound so it can mount the next cartridge on the same tape transport.

Tape transport contention can be reduced by:

• ensuring scratch cartridge balance

• managing multi­host tape transports

• avoiding dedicating tape transports

• using two tape transports for multi­volume files.

Reduce Scheduling Contention

Effective scheduling can increase library performance. Controlling the following scheduling related areas can help significantly in further increasing library performance:

• strive for a balanced workload

• schedule nonproductive library activities during low­demand times.

Balancing the Workload

If you experience higher than expected average mount times but at the same time experience an improvement in production throughput, it could be an indication that your system is periodically flooded with work rather than having a balanced workload.

For example, all of your production jobs may be getting submitted at the beginning of a shift so that the library robots are overworked for the first few hours of the shift. Then, the robots may remain idle for the remainder of the shift. If you are using a scheduling software package and it releases jobs every hour on the hour, there may be tremendous tape transport contention for the first few minutes of each hour while the transports are unused for the remainder of each hour.

These situations tend to elevate average mount times; however, as long as the work is performed on time, there is probably no need to change conditions. However, if the work is not getting performed on schedule, you can improve performance by balancing your production workload.

Scheduling Nonproductive Activities During Low­Demand Times

There are several library utilities, which, though very essential, severely impact the library's ability to mount and dismount cartridges. The following utilities should not be run when high­priority production jobs are pending:

• AUDIt

• EJECt

• Initialize Cartridge

• MOVe

• Scratch Redistribution

• Scratch Update.

These utilities should be scheduled during quiet periods so they do not contend with mounts and dismounts. Running these activities during quiet periods also makes sure that the tasks complete faster. In the case of mass enters or ejects, operator's time can also be optimized.