Implementation overview - syncsort_scc_monitor

SCC-DLimit uses the Dynamic Install Facility (DIF) to interface with the operating system and to control product operation. DIF provides facilities for dynamic installation of the product operating system routines, console communications, SCC-DLimit rule loading, and management of the SCC-DLimit product modules that reside in the Common System Area (CSA).

Important:

This section assumes that the SCC installation procedures found in the Product Installation Guide have been performed and the SCC-DLimit load modules have been linked into an authorized load library. For more information, refer to Installation in the Product Installation Guide.

Once the DLimit load modules have been installed into an APF-authorized library, DLimit can be started. However, before DLimit can do any useful work, several additional tasks must be completed. The following checklist summarizes the steps required to implement DLimit:

Perform Product Verification for DLimit as described in Chapter 3
Allocate and format the DLimit database file
Authorize DLimit TSO commands and resources
Customize default database account settings
Customize the rules language for your installation
Populate the DLimit database
Activate DLimit in the DIF task
Install the ISPF interface

Step 1 - Allocate and Format the DLimit Database

Note: If this step has already been performed during product verification, and no changes are desired to the database at this time, proceed to step 2.

A BDAM file must be allocated for DLimit to use as its default database. DLimit keeps information about each disk space account (account name, current utilization, high-water mark, and budgeted space limit) in the database.

The following JCL contains two steps. The first step runs IEFBR14 to allocate the DLimit database. The second step executes program DLMAINT located in the DTS.R71.LOADLIB to format the file and create database accounts. The JCL appears as:


//JOBNAME JOB .... (RC=0 expected)
//*
//* THIS IS THE Storage Control Center DLIMIT DATABASE FORMAT JOB
//*
//STEP1 EXEC PGM=IEFBR14
//SYSPRINT DD SYSOUT=*
//RRDS DD DSN=DTS.DSLR71.DSLDB,DISP=(NEW,CATLG,DELETE),
//      SPACE=(CYL,(5,2)),UNIT=SYSALLDA
//*
//STEP2 EXEC PGM=DLMAINT
//STEPLIB DD DISP=SHR,DSN=DTS.R71.LOADLIB
//SYSPRINT DD SYSOUT=A
//RRDS DD DISP=SHR,DSN=DTS.DSLR71.DSLDB
//SYSIN DD *
SET DATABASE(BDAM(RRDS FORMAT)) DLSYS
DLADD MODEL MODE(WARN) WARN(80) MAX(100M)
DLADD MODELP MODE(ACTIVE) WARN(85) MAX(5G)
DLADD TEST1 MODEL(MODEL)
DLADD PROD MODEL(MODELP)
DLLIST MODEL
DLLIST MODELP
DLLIST TEST1
DLLIST PROD
/*

Figure 4-1. JCL to Allocate and Format the DLimit Database

Step 2 - Add the DLimit Commands to the TSO Authorized Command Table

The $CONTROL record specifies the system-wide defaults used by DLimit. The DLimit TSO commands are used to create and update the DLimit database, including the $CONTROL record. These commands reside in the DLimit load library, which must be APF-authorized.

The $CONTROL record in the DLimit database specifies product defaults. The DLSYS command is used to set or change values in the $CONTROL record. The DLSYS command and the other DLimit TSO commands should be placed in the TSO Authorized Program table, IKJTSOxx.

When creating accounts, an existing account may be used as a model. To add an account, use the DLADD command; to modify, use DLALTER; to establish a model account, specify its name with the MODEL parameter on DLADD or dynamically in the rules.

The following commands and program must be added to the TSO authorized command table and program lists:

The following commands should be added to the AUTHCMD list in IKJTSOxx:

DLADD
DLALTER
DLDEL
DLLIST
DLSYS

The following program name should be added to the AUTHPGM and AUTHTSF list in IKJTSOxx:

DLMAINT

The TSO PARMLIB update command can be used to update the TSO authorized command table.

Step 2b - Protect the DLimit Resources

The DLimit database contains aggregated space information about accounts used by many users. The DLimit database administrator can define/delete accounts, change limits, and perform other tasks affecting the system.

Users who are not database administrators cannot view or update the DLimit database (except implicitly when creating or deleting datasets) unless they have authority to the appropriate FACILITY class resource. Before DLimit allows access, the user's authority is checked. The FACILITY class resource name format is DSL.acctname, where acctname is the DLimit account name. The special account name $CONTROL is used for updates to the control record.

The database administrator should have ALTER authority to the DSL.$CONTROL resource within the FACILITY class. All other users should have READ authority. Use the RACF RDEFINE and PERMIT commands to define and permit access to the resources. Example:

RDEFINE FACILITY DSL.$CONTROL UACC(READ)
PERMIT DSL.$CONTROL CLASS(FACILITY) ID(<TSO-user-id>) ACCESS(ALTER)

ALTER authority is required to issue the DLSYS command or perform updates to the $CONTROL record through the ISPF interface. CONTROL authority is required to explicitly add or delete accounts via DLADD or DLDEL.

To allow all users to view (but not update) accounts, define a generic resource profile:

RDEFINE FACILITY DSL.* UACC(READ)

After updates to FACILITY class resources, refresh the instorage RACF tables via:

SETROPTS RACLIST(FACILITY) REFRESH

The security interface within SCC-DLimit uses standard System Authorization Facility (SAF) calls and works with any RACF-compatible system. Users of other security systems should consult their documentation.

Step 3 - Customize Default Database Account settings

Set defaults in the $CONTROL record.

When the $CONTROL record is created via the DLSYS command, SCC-DLimit defaults are set. The DLSYS command is more fully documented in the DLimit TSO Commands section of this manual. It may be useful to execute the DLSYS command again after the

$CONTROLrecord has been created in order to change DLimit defaults. Some of the defaults which may be set are:

Operation mode
Automatically create new accounts
Operation Mode

Most installations place DLimit in WARNing mode, in which warning messages are issuedto the JES log or TSO user when the space limits for an account are exceeded. The operation mode may also be set to ACTIVE, which will fail allocations that ask for more space than allowed, or TRACK, which merely records space without checking to see whether space limits have been exceeded. Space recording can also be temporarily dis- abled by placing the system in INACTIVE mode. The operation mode may be set at the level of the entire system via the DLSYS command, or at the level of individual accounts via the DLALTER command.
Automatically Create New Accounts
WhenDLimit processes a request for space from the operating system, it uses the product rules which were specified at the time DLimit was started in order to determine the account to which space is to be assigned. If a SET &DACCT= rule statement which applies to the dataset is encountered, then the space is assigned to the specified account. If the account does not exist, DLimit can automatically create them at the time they are needed. The DLSYS AUTOCREATE(ACTIVE) parameter can be used to indicate to DLimit that new accounts are to be automatically created.

In the following example, the SET DATABASE control statement identifies the DLimit database.The defaults are set in the $CONTROL record via the DLSYS control statement and it’s parameters. The MODE value of WARN indicates that a warning message is to be issued when the space for an account exceeds its specified limit. The value of ACTIVE for AUTOCREATE indicates that a new account may be dynamically created when a SET &DACCT= statement is encountered for which the specified account does not already exist. LIST indicates that the values in the $CONTROL record are to be displayed after being set.

The following JCL can be found in the DSLCNTRC member of the Storage Control Center sample library: DTS.R71.SLyyddd.SAMPLIB. The job contains the JCL and DLSYS control statements necessary to update the $CONTROL record. Fields represented with bold type may need to be modified before submission.
```
//JOBNAME JOB .... (RC=0 expected)
//*
//* JOB TO UPDATE THE DLIMIT $CONTROL RECORD
//*
//STEP1 EXEC PGM=DLMAINT
//STEPLIB DD DISP=SHR,DSN=DTS.R71.LOADLIB
//SYSPRINT DD SYSOUT=A
//RRDS DD DISP=SHR,DSN=DTS.DSLR71.DSLDB
//SYSIN DD *
SET DATABASE(BDAM(RRDS))
DLSYS AUTOCREATE(ACTIVE) MODE(WARN) LIST
/*
```
Figure 4-2. JCL to Update the $CONTROL record

Step 3a - Create MODEL accounts in the DLimit Database

The recommended name for the model account is MODEL.

Define a MODEL account via the DLADD command. Example JCL to add a model account:


//JOBNAME JOB .... (RC=0 expected)
//*
//* JOB TO CREATE A MODEL ACCOUNT
//*
//STEP1 EXEC PGM=DLMAINT
//STEPLIB DD DISP=SHR,DSN=DTS.R71.LOADLIB
//SYSPRINT DD SYSOUT=A
//RRDS DD DISP=SHR,DSN=DTS.DSLR71.DSLDB
//SYSIN DD *
SET DATABASE(BDAM(RRDS))
DLADD MODEL MODE(WARN) WARN(90) MAX(100M) DLLIST MODEL
/*

Figure 4-3. JCL to Add a MODEL Account

Step 3b - Define DLimit Space Accounts

Accounts may be created dynamically when AUTOCREATE(ACTIVE) is set; otherwise create accounts explicitly with DLADD and modify with DLALTER. Example JCL to add static accounts:


//JOBNAME JOB .... (RC=0 expected)
//*
//* JOB TO ADD STATIC ACCOUNTS
//*
//STEP1 EXEC PGM=DLMAINT
//STEPLIB DD DISP=SHR,DSN=DTS.R71.LOADLIB
//SYSPRINT DD SYSOUT=A
//RRDS DD DISP=SHR,DSN=DTS.DSLR71.DSLDB
//SYSIN DD *
SET DATABASE(BDAM(RRDS))
DLADD TESTA MODE(WARN) WARN(80) MAX(50M)
DLADD TESTB MODEL(MODEL)
DLLIST TESTA
DLLIST TESTB
/*

Figure 4-4. JCL to Add Static Accounts

Step 4 - Customize the Rules Language for Your Installation

OnceDLimit operation has been verified, the DLimit rules should be customized to assign accounts for datasets which are appropriate at your installation. This customization facility uses a CLIST-like rules language which is used by all DTS Software products. The SCC Rules Language Programming Guide contains customization and reference chapters for the rules language. These chapters document the structure and location of the rules, as well as providing a general overview on using the rules language.

Oncethe rules have been established, the RESYNC command of the DLMAINT batch utility can be run to initially populate the DLimit database with information about the space occupied by existing datasets.

The primary function of the DLimit rules is to assign requests for space to an account. The DLimit rules are executed whenever the system makes a request for space on a volume. When coding the DLimit rules, it is advisable to use durable variables when determining what account to assign. That is, the rules should test and use variables which will not change between executions. It is better to use &QUAL1 than &STEPNAME or &DDNAME, for example, since the high-level qualifier of a dataset is unlikely to change, whereas the stepname or DD name assigned to a dataset may differ from one job to the next. The following example assigns a request for space to one of several different accounts, depending upon the value of various qualifiers of the dataset name and the type (permanent or temporary) of the space required:

The rules reside in a member of the partitioned dataset specified by the PARMLIB DD statement in the DIF catalogued procedure. The default name for the DLimit rule member is DSLRULES. A request for space is assigned to an account by the SET &DACCT= statement. Requests for space may be assigned to up to 10 accounts. If the rules do not specify a MODEL account to be used, then the default values specified in the $CON- TROL record are used. MODEL accounts must be predefined using the DLADD state- ment of the DLMAINT utility. It is recommended that MODEL accounts be specified if an account had not been previously defined.

Typically,requests for space are assigned to one or more accounts, representing the appli- cation owner, a departmental group, and possibly a larger administrative unit. As datasets are created, extended, deleted, renamed, and space released, the appropriate space amounts are added to or subtracted from the accounts as needed. In this way, an up-to-date running total of the space occupied by the application, department, or other organization is always maintained. The example below shows a typical manner of assigning request for space to multiple accounts.

DEFRULE SOMERULE
IF &QUAL1 EQ PROD*
   &QUAL3 EQ DEPT29
   &RACF_OWNER EQ USR32*
   &TEMP EQ NO
THEN
   SET &DACCT1 = PRODUCTION
   SET &DACCT2 = &RACF_OWNER
   SET &DACCT3 = &QUAL3
   SET &DACCT4 = 'GEORGIAPLANT'
   SET &DACCT5 = '&DACCT1:PERM'
   SET &MODEL = MODEL

To enable rule tracing during processing, add the following DD statement to the job:

//DSLTRACE DD DUMMY

Step 5 - Populate the DLimit Database

When the DLimit database is created, it is initially empty. That is, there are no entities (otherthan the $CONTROL account) and existing used disk space is not accounted for. In order to update the DLimit database to reflect the DASD space currently used by datasets, the DLMAINT utility should be run to examine the space currently used and assign it to the desired DLimit accounts. The RESYNC command of DLMAINT is used to read the VTOCs of specified volumes and invoke the DLimit rules for each dataset on the volumes. The HSM command of DLMAINT can also be used, if desired, to examine the DFSMShsm Migration Control Dataset to obtain dataset information and invoke the DLimit rules for each migrated dataset in order to initially populate the DLimit database.

Establish Rules to Assign Accounts

Before running DLMAINT RESYNC to obtain information on existing datasets, rules must be established to assign the datasets to appropriate accounts. Since variables such as job name and DD name will be unavailable for datasets which already exist, it makes sense to use "durable" variables such as high-level qualifier and RACF owner id to assign datasets to accounts. Such variables are associated with the dataset, rather than any partic- ular job or user. Using durable variables ensures that when datasets are deleted, recreated, or have space released, the space amount is always added to or subtracted from the same account. Once rules have been established which identify the desired datasets and assign them to accounts, the RESYNC control statement of the DLMAINT program can be exe- cuted to process each dataset and assign its space to a DLimit account. The RESYNC statement can invoke either the default rules or a special set of rules specified via the SET RULES statement.

A sample DLimit rule set is shown below. These rules use the second-level qualifier of the dataset name as the DLimit account name for permanent datasets. If allowed by the

$CONTROLrecord, accounts will be automatically created. The default values in the MODEL account is used to assign the space for the dataset.

DEFRULE RESYNCRL
IF &QUAL2 NE ''
   &TEMP EQ NO
THEN
   SET DACCT1 = &QUAL2
   SET MODEL = MODEL

Run RESYNC to Populate the SCC-DLimit Database

The JCLbelow shows an example of how the RESYNC control statement can be used to populate the DLimit database. In this example, the INCLUDE VOLUME statement is included to specify which volumes DLMAINT is to process. Note: When running RESYNC to populate the production SCC-DLimit database, the INCLUDE VOL- UME statement would be removed to initialize accounts that would accurately track space usage.

The RESYNC statement is used to create or update records in the SCC-DLimit database to reflect the amount of space occupied by datasets on DASD volumes. Further information on the RESYNC statement is included in the DLMAINT Program section of this manual.

A sample RESYNC job can be found in the DSLRSYNC member of the Storage Control Center sample library: DTS.R71.SLyyddd.SAMPLIB. The job contains sample JCL to run RESYNC to load the DLimit database with space usage information. The JCL and control statements used for the sample RESYNC job are shown below. Fields represented with bold type may need to be modified before submission.


//JOBNAME JOB .... (RC=0 expected)
//*
//* RESYNC UTILITY JOB
//*
//STEP1 EXEC PGM=DLMAINT,REGION=4M
//STEPLIB DD DISP=SHR,DSN=DTS.R71.LOADLIB
//PARMLIB DD DSN=DTS.R71.PARMLIB,DISP=SHR
//        DD DSN=DTS.SCCR71.RULELIB,DISP=SHR
//SYSPRINT DD SYSOUT=A
//RRDS DD DISP=SHR,DSN=DTS.DSLR71.DSLDB
//SYSOUT DD SYSOUT=A
//SYSUT1 DD SPACE=(CYL,(50,0)),UNIT=VIO
//SYSUT2 DD SPACE=(CYL,(50,0)),UNIT=VIO
//SYSUT3 DD SPACE=(CYL,(10,0)),UNIT=VIO
//SYSIN DD *
SET DATABASE(BDAM(RRDS))
SET MODE(SIMULATE)
SET RULES(NAME(DSLRSYNR) DDNAME(PARMLIB))
INCLUDE VOLUME(STOR01)
VOLUME(LOCK) RESET CLEAR(ALL) RESYNC DETAIL SHOW LIST
/*

Figure 4-5. Sample DLMAINT RESYNC JCL

In the preceding example, the MODE is set to SIMULATE. This is recommended until you're certain that RESYNC is properly processing all the desired datasets and assigning accounts and categories as desired. At that time, the SET MODE statement should be changed to NOSIMULATE (or eliminated to allow the default of NOSIMULATE) and the INCLUDE VOLUME statement removed to scan all volumes on the system.

The SET RULES statement specifies a member in the PARMLIB partitioned dataset. If theSET RULES statement is not present, the active rule set, specified when SCC-DLimit was started via a START DSL command to DIF, will be used. The DSLRSYNR member of the sample library contains a set of SCC-DLimit rules which assign space to account names which are the same as the first two qualifiers of the dataset name. An additional account will be assigned based on the file type as either ’VSAM’ or ’NONVSAM’. You will want to change the sample rules to correspond to your installation’s needs.

The INCLUDE VOLUME statement specifies which volumes SCC-DLimit is to process. Since no INCLUDE DATASET or EXCLUDE DATASET statements are present, all datasets on the specified volumes are processed. For each dataset, the SCC-DLimit rules are examined, and if a SET &DACCT= statement is encountered which applies to the dataset, the space is assigned to the specified account. In the example, volume STOR01 is processed.

The VOLUME(LOCK) statement indicates that the dadsm exits will not add or subtract space values for accounts on the volumes that haven’t been process during RESYNC. As RESYNC completes processing on each volume the lock is released allowing DLimit updates.

The RESET CLEAR(ALL) statement initializes the high water mark, current amount, and maximum amount account fields to zero.

The RESYNC statement specifies that SCC-DLimit accounts are to be created or updated.

The DSCBs for the dataset are read and the amount of space occupied by the dataset is calculated.
TheSCC-DLimit rules are processed for the dataset. IF statements within the rules may examine any of the SCC-DLimit variables, such as &VOLSER, &QUALn, &DSORG, and so forth.
If a SET &DACCT= statement is encountered while processing the rules which apply to the dataset, an SCC-DLimit database record is written to the SYSUTx files. This record will later be used to update the SCC-DLimit database.

The following figure shows some sample output from a DLMAINT RESYNC statement. In this example, several datasets residing on the STOR01 volume are processed. There are four different sections to the report.

The first section echoes the control statements and displays the options that are in effect during the RESYNC job.

The next section is the Dataset Detail Report. This section shows, for each dataset processed, what accounts were assigned by the SCC-DLimit rules and the amount of space occupied by the dataset. This section may be suppressed by specifying NODSNDETAIL.

The next section is the Account Detail Report. This section is produced by specifying the DETAIL keyword (this is the default). The Account Detail Report shows the amount of space actually occupied by datasets for each account on the specified volumes, the amount of space currently accounted for in the SCC-DLimit database and the difference between the two.

The final section of the output shows theAccount Detail Report again, this time after all SCC-DLimit accounts have been updated. Original and final balances for each account are displayed. Finally, statistics are displayed indicating how many volumes, datasets, and accounts were processed.

SCC-DLIMIT DLMAINT UTILITY PROCESSING

DSL40010-I CONTROL STATEMENT: SET DATABASE(BDAM(RRDS))

DSL40010-I CONTROL STATEMENT: SET MODE(SIMULATE)

DSL40010-I CONTROL STATEMENT: SET RULES(NAME(DSLRYSNR) DDNAME(PARMLIB))

DSL40010-I CONTROL STATEMENT: INCLUDE VOLUME(STOR01)

DSL40010-ICONTROL STATEMENT: RESYNC DETAIL CLEAR
DSLIVP:ACCOUNT(S) (DTS ) ASSIGNED TO DATASET DTS.IMS.MACLIB
DSLIVP:ACCOUNT(S) (DTS ) ASSIGNED TO DATASET DTS.ABCVSAM.DATABASE.DATA
DSLIVP:ACCOUNT(S) (DTS DTS:VSAM) ASSIGNED TO DATASET DTS.ABCVSAM.DATABASE.DATA
          DSLIVP: ACCOUNT(S) (DTS ) ASSIGNED TO DATASET DTS.A
DSLIVP: ACCOUNT(S) (DTS ) ASSIGNED TO DATASET
          DTS.SMPE.TRSMAIN.UNLLOAD DSLIVP: ACCOUNT(S) (DTS ) ASSIGNED TO DATASET
          DTS.SMPE.TRSMAIN.LOADLIB DSLIVP:ACCOUNT(S) (DTSV ) ASSIGNED TO DATASET DTSV.ABCVSAM.DATABASE.DATA
DSLIVP:ACCOUNT(S) (DTSV DTSV:VSAM) ASSIGNED TO DATASET DTSV.ABCVSAM.DATABASE.DATA
          DSLIVP: ACCOUNT(S) (MONAV ) ASSIGNED TO DATASET MONAV.SRSTEST.DATA
DSLIVP:ACCOUNT(S) (MONAV MONAV:VSAM) ASSIGNED TO DATASET MONAV.SRSTEST.DATA DSLIVP:
          ACCOUNT(S) (MONA ) ASSIGNED TO DATASET MONA.CATDB.DATA
DSLIVP:ACCOUNT(S) (MONA MONA:VSAM) ASSIGNED TO DATASET MONA.CATDB.DATA DSLIVP:
          ACCOUNT(S) (MONA ) ASSIGNED TO DATASET MONA.IEFBR14
DSLIVP: ACCOUNT(S)(MONA ) ASSIGNED TO DATASET MONA.IDCAMS
.
.
. 
DSL41600-IDTSDTS.ASTOR0156.312K
DSL41600-I DTS.ABCVSAM.DATABASE.DATASTOR0116.497M
DSL41600-I DTS.IMS.MACLIBSTOR0156.312K
DSL41600-I DTS.SMPE.TRSMAIN.LOADLIBSTOR01450.500K
DSL41600-I DTS.SMPE.TRSMAIN.UNLLOADSTOR01563.125K
.
.
.
    
DSL41601-IDTS  772.152M1.688G956.707M
 
DSL41600-I
 
DTS:VSAM
 
DTS.ABCVSAM.DATABASE.DATA
 
STOR01
 
16.497M
  
DSL41600-I DTS.ABCVSAM.DATABASE.INDEXSTOR0156.312K  
DSL41601-IDTS:VSAM  16.552M0.000B16.552M
 
.
.  
.
 
DSL41602-IEND OF REPORT
 
 
DSL41700-IACCOUNT                         OLD         NEW
 
DSL41700-IDTS                                  0.000B     772.152M
DSL41700-IDTS:VSAM                             0.000B     16.552M
DSL41700-IDTSV                                 0.000B     
            16.552M
DSL41700-IDTSV:VSAM                            0.000B     
            16.552M
DSL41700-IMONA                                 0.000B     
            65.221M
 
 
DSL41700-IMONA:VSAM                            0.000B     
          18.202M
DSL41700-IMONAV                                0.000B     
          48.228M
DSL41700-IMONAV:VSAM                           0.000B     
          48.228M
 
 
 
DSL40004-I 506 DATASETS PROCESSED BY DLMAINT 
DSL40005-I 1 VOLUMES PROCESSED BY DLMAINT
 
DSL40010-I CONTROL STATEMENT: SHOW LIST 
DSL41100-I $CONTROL
DSL41100-I DTS 
DSL41100-I DTS:VSAM 
DSL41100-I DTSV 
DSL41100-I DTSV:VSAM
DSL41100-I DTSVSAM 
DSL41100-I IVP 
DSL41100-I MONA 
DSL41100-I MONA:VSAM 
DSL41100-I MONAV
DSL41100-I MONAV:VSAM 
DSL41100-I MONAVSAM
DSL40003-I 12 ACCOUNTS PROCESSED BY DLMAINT
 
DSL40002-I DLMAINT PROCESSING COMPLETED

Figure 4-6. Sample DLMAINT RESYNC Output

Step 6 - Activate DLimit in the DIF task

Start DLimit

Before DLimit space accounting takes place, DLimit must be running and active in the system. Copy your customized rule member (e.g., DSLRULES) to the Rulelib dataset referenced by the //PARMLIB DD in the DIF started task, then start DLimit with the DIF START command. Example command:

F DIF,START DSL

Step 7 - Install the ISPF Interface

The DLimit ISPF interface provides an alternative to the DLxxx TSO commands. It allows users to examine account values and run batch jobs; administrators can set defaults, change account information, and copy/restore the database.

During SCC installation, ISPF files were copied to the DIF ISPF library: DTS.R71.ISPFLIB. Concatenate this library into existing ISPF panels/messages/skeleton libraries in your TSO logon procedures. If not already done, run the provided member CDSLINIT in that library to perform the necessary LIBDEF and ALTLIB commands (or use the sample CDSLINIT member to temporarily concatenate the DLimit libraries to a user's ISPF environment).

Backup and Restore of DLimit Databases

The Dlimit database should be periodically backed up so that it can be recovered in the eventof a system failure. It may also be useful to make a backup copy of the DLimit data- base for reporting purposes. The DLimit database may be backed up while DLimit is active. The DLMAINT Utility described in Chapter 7 is used to back up and restore the DLimit database. After a restore to an alternate database, the DLMAINT utility can again be run to examine and update data or produce reports without disturbing the active DLimit database. The following JCL shows an example of backing up a DLimit database to a sequential file and restoring it to an BDAM file. The BDAM target of the restore must have been previously allocated and formatted as shown before the restore can take place.

Run DLMAINT to back up the DLimit database

//***********************************************
 //* BACK UP THE DLIMIT DATABASE *
 //***********************************************
 //DLMAINT EXEC PGM=DLMAINT,REGION=4M
 //BKUPFILE DD DSN=DSL.BKUP.FILE,DISP=(,CATLG),UNIT=SYSDA,
 //       SPACE=(CYL,(1,1),RLSE)
 //SYSPRINT DD SYSOUT=*
 //SYSIN DD *
 INCLUDE ACCOUNT(*)
 BACKUP TODD(BKUPFILE)
 /*

Format a DLimit Database for Restore

//**************************************************
 //* ALLOCATE AND FORMAT A DLIMIT DATABASE TO SERVE *
 //* AS THE TARGET OF THE RESTORE *
 //**************************************************
 //ALOC EXEC PGM=IEFBR14
 //SYSPRINT DD SYSOUT=*
 //RRDS DD DSN=DSL.RESTORE.DB.TARG,DISP=(NEW,CATLG,DELETE),
 //     SPACE=(CYL,(5,2)),UNIT=SYSALLDA
 //FORMAT EXEC PGM=DLMAINT
 //STEPLIB DD DISP=SHR,DSN=DTS.R71.LOADLIB
 //SYSPRINT DD SYSOUT=*
 //RRDS DD DISP=SHR,DSN=DSL.RESTORE.DB.TARG
 //SYSIN DD *
 SET DATABASE(BDAM(RRDS FORMAT))
 /*

Restore the DLimit Database

//**************************************************
 //* RESTORE THE DLIMIT DATABASE FROM A BACKUP *
 //**************************************************
 //DLMAINT EXEC PGM=DLMAINT,REGION=4M
 //BKUPFILE DD DISP=SHR,DSN=DSL.BKUP.FILE
 //RRDS DD DISP=SHR,DSN=DSL.RESTORE.DB.TARG
 //SYSPRINT DD SYSOUT=*
 //SYSIN DD *
 SET DATABASE(BDAM(RRDS))
 RESTORE FROMDD(BKUPFILE) ALL CONTROL LIST
 /*

Disk Space Management System Considerations

Migrated Data

DLimit will process all requests for direct access space in the system, including requests for space for migrated datasets and requests for space for datasets to be recalled from migrated status. For installations which use IBM's DFSMShsm to migrate and recall data- sets, the following considerations may be important:

DuringDFSMShsm migration, the original dataset which resided on DASD is deleted and re-catalogued with a volume serial number of MIGRAT to indicate that it has been migrated. DLimit will receive control during scratch processing for the original dataset and can process it in the same manner as any other scratched dataset. That is, the DLimit rules will be executed, and if the space is assigned to a DLimit account via the SET &DACCT= statement, then the space for the dataset will be subtracted from the DLimit account.

If the dataset migrates to ML1 DASD, DFSMShsm compresses the data and stores it in a file named:

prefix.HMIG.Tssmmhh.qual1.qual2.Xyddd

where'prefix' is a value specified by the DFSMShsm SETSYS MIGRATEPREFIX com- mand, 'HMIG' and 'T' are constants, and 'qual1' and 'qual2' are the first two qualifiers of the dataset name being migrated. During migration processing, the request for ML1 space will be presented to DLimit using this name. If space is to be tracked for migrated datasets using dataset qualifiers as a selection criteria, then it is important to use only the first two qualifiers of the dataset name, since these are the only parts of the dataset name known to DLimit at the time the request is made for ML1 space. Of course, other variables besides dataset name qualifiers, such as RACF owner id, can also be used to identify a dataset and assign it to an account; however, in this case, DLimit cannot account for the migrated space.

DLimit does not currently track space for datasets migrated to ML2 or to SDSPdatasets. (Except that the space occupied by SDSP datasets themselves is tracked). The HSM command of the DLMAINT utility program can be used to initially populate the DLimit data- base with the space occupied by migrated datasets if desired.

FDRABR Archiving: When FDRABR migrates datasets to DASD, all of the datasets from a volume are placed in a single sequential file. Datasets may be individually restored from this file. DLimit will track the deletion of datasets that occurs as part of FDRABR archive processing, and will also track the creation of FDRABR archive backup files (datasets with a name of the form FDRABR.Vvolser.Bxyydddn). When datasets are restored from archive, DLimit will track the space occupied by the datasets when they are restored. Space occupied by indi- vidual files within an archive backup is not tracked.

Multivolume Datasets: DLimittracks the creation, deletion, and extension of multivolume datasets just as it does any other dataset. There are no special considerations for multivolume datasets.

Idle Space Release or Volume Restore

DFSMShsm daily space management and other utilities may be run to release occupied but unused space from DASD datasets. If the utility which performs idle space release does so via the REALLOC SVC, the IGGPRE00 and IGGPOST0 exits will be invoked, and the DLimit rules will be driven to account for the released space. However, if the space is released by directly modifying the VTOC and VVDS entries for datasets (as is doneby Innovation Data Processing's COMPAKTOR), then IGGPRE00 and IGGPOST0 are not entered, and DLimit will not be aware of the release of space. In this case, it may be useful to run the RESYNC statement of the DLimit DLMAINT utility, to allow the space occupied by datasets on the volume to be redetermined.

Restoreof an individual dataset, whether via FDRABR, DFSMShsm, DFSMSdss, or other utilities, is normally performed using system allocation routines, and the space occupied by the restored dataset is accounted for by DLimit. However, when an entire volume is restored, this process usually is performed directly by the DASD management utility, out- side of the normal dataset allocation process. After a full-volume restore, DLMAINT RESYNC should be run to update the DLimit accounts for space occupied by datasets residing on the volume.

VSAM Sphere Processing: DLimitprocesses each component of a VSAM sphere separately. That is, the DLimit rules are entered once for the data component of a VSAM cluster, once for the index compo- nent, and so on. For VSAM datasets, the &DSNAME variable in the DLimit rules con- tains the name of the VSAM component currently being processed. To use the name of the VSAM cluster, use the &CLUSTER variable, or alternatively, use any dataset name quali- fiers except the last qualifier for both VSAM and non-VSAM datasets. For non-VSAM datasets, the &CLUSTER variable contains the non-VSAM dataset name.

DLIMIT and DFSMShsm Recalls

DLimit can receive control during recalls of datasets migrated by DFSMShsm. Typically, accounts are assigned in the ALLOCATE environment (rules see &ENV = ALLOCATE). The ARCRPEXT environment can receive control during recalls to prioritize or deny recalls. To use ARCRPEXT, ensure the DFSMShsm ARCRPEXT exit is active and the ARCRPEXT alias is available in a linklist or STEPLIB accessible to DFSMShsm. Activate the exit with SETSYS EXITON(RP).

Environment Description

The Return Priority (RP) environment receives control when a recall request is placed on DFSMShsm work queues or when requests must wait. ARCRPEXT processes SMS and non-SMS datasets and volumes.

Uses of the Return Priority Environment: Use RP to prioritize DFSMShsm requests (e.g., production recalls over TSO). ARCRPEXT can also prevent requests (HDELETE, etc.) or prompt operator confirmation. To enable ARCRPEXT rules, the DFSMShsm ARCRPEXT exit must be linked into a linklist and enabled via SETSYS EXITON(RP).

When the ARCRPEXT Environment is Entered: The environment is entered for recall, recover, or delete requests that must wait, after the Management Work Element (MWE) is built but before being queued. Both SMS-managed and non-SMS requests are processed.

Variables in the ARCRPEXT Environment

The following variables are available to DLimit rules in ARCRPEXT. The default for &BYPASS_REQUEST is NO.

Table 4-1. Symbolic Variables in the ARCRPEXT Environment

SYMBOLIC NAME	Value	DESCRIPTION
ENV	ARCRPEXT	DFSMShsm dataset or volume prioritization exit
ENVS	RECALL, RECOVER, DELETE	Type of processing request
DSNAME	44-character dataset name	Blank for volume requests
BYPASS_REQUEST	YES/NO	Setting to YES purges the MWE and cancels the request
PRIORITY	0–100	Priority for the request (default 50)
PRIORITY_NOWAIT	YES/NO	Whether PRIORITY applies to NOWAIT requests (default NO)
REQUEST_SOURCE	HSM, TSO, TSOBATCH, BATCH	Source of request
REQUEST_TYPE	WAIT/NOWAIT	Request wait behavior
RECOVER_TYPE	DATASET/VOLUME/INCRE	Type of recovery
COMMAND_TYPE	DATASET/VOLUME	Level of command
DATA_SOURCE	TAPE/DASD	Device type for recovery
DATA_SOURCE_VLD	YES/NO	Validity of DATA_SOURCE
USERID	8-character id	ID initiating the request
RP_MSGn	RP_MSG1..RP_MSG5	Optional messages written to DFSMShsm logs

Installing and Activating the ARCRPEXT Environment

Before the DLIMIT rules can use the ARCRPEXT environment, the necessary DFSMShsm exit, supplied in the DLIMIT load library, must be linked into a linklist libraryand the appropriate DFSMShsm SETSYS commands issued. The following steps are required:

Link module DSL0009 with alias ARCRPEXT into an APF-authorized load library (linklist or STEPLIB). Example link JCL:


                        //LINKJOB JOB ...
                        //LINK EXEC PGM=IEWL,PARM='RENT,REUS,AC=1'
                        //SYSUT1 DD UNIT=SYSALLDA,SPACE=(CYL,(1,1))
                        //SYSPRINT DD SYSOUT=*
                        //PRODLIB DD DISP=SHR,DSN=DTS.R61.SLyydd.LOADLIB
                        //SYSLMOD DD DISP=SHR,DSN=apf.linklist.library
                        //SYSLIN DD *
                        INCLUDE PRODLIB(DSL0009) ALIAS ARCRPEXT
                        NAME DSL0009(R)
                        /*

Refresh LLA after linklist changes: operator command:
```
MODIFY LLA, REFRESH
```
Enable the ARCRPEXT exit via DFSMShsm SETSYS command (place in ARCCMDxx member):
```
SETSYS EXITON(RP)
```

Note: Some DFSMShsm releases may require SETSYS EXITOFF(xx) prior to SETSYS EXITON(xx). Use DFSMShsm QUERY SETSYS to verify the exit is loaded and enabled.

Examples for the ARCRPEXT Return Priority Exit

Example 1 - Prioritize or Prevent DFSMShsm Recalls

The following example rules demonstrate how to prioritize or prevent recalls:

DEFENV ARCRPEXT MODE(ACTIVE)
DEFRULE RCALPRTY
IF &ENV NE ARCRPEXT THEN CONTINUE AT NEXTRULE

/*********************************************/
/* PRODUCTION RECALLS HAVE ABSOLUTE PRIORITY */
/*********************************************/
IF &QUAL2 = PROD*
   &ENVS = RECALL
THEN SET &PRIORITY = 100

/*********************************************/
/* HIGH PRIORITY FOR SYSPROG RECALLS */
/*********************************************/
IF &ENVS = RECALL
   &REQUEST_SOURCE = TSO
   &USERID = STGADM*
THEN SET &PRIORITY = 75

/**********************************************/
/* LOW PRIORITY FOR DAYTIME TAPE RECALLS */
/**********************************************/
IF &ENVS = RECALL
   &DATA_SOURCE = TAPE
   &CURTIME GT 09:00:00
   &CURTIME LT 17:00:00
   &CURDAY NE (SATURDAY,SUNDAY)
THEN SET &PRIORITY = 40

/**********************************************/
/* WARN/PREVENT RECALLS OF OBSOLETE DATA */
/**********************************************/
IF &ENVS = RECALL
   &DSNAME = OLD.DATA.*
THEN SET &BYPASS_REQUEST = YES
     ISSUE WRITEMSG(EMSG1)

DEFMSG EMSG1
'RECALL BYPASSED FOR OLD DATASET &DSNAME. CONTACT SYSPROG' USERID(&USERID)

Implementation overview - syncsort_scc_monitor - Latest

Syncsort™ Storage Management SCC DLimit Guide

Backup and Restore of DLimit Databases

Disk Space Management System Considerations

DLIMIT and DFSMShsm Recalls

Installing and Activating the ARCRPEXT Environment

Examples for the ARCRPEXT Return Priority Exit