HSM Tape and Dataset tips

Recall failures on large datasets
Replacing a damaged ML2 tape
ML1 pool full
SDSP datasets full
Recall failures on ML1 datasets
HSM locking out batch job creating a GDG
Empty dataset processing
Reclaiming tapes that are almost empty
Recovering a dataset which has already been recalled from HSM

Recalls

If you are having difficulty finding space to recall a large dataset, you have two options. You can force it to go multi-volume, or you can direct it to an empty, non-SMS disk. The commands are

HSEND RECALL datasetname DFDSSOPTION(VOLCOUNT(ANY))

HSEND RECALL datasetname FORCENONSMS UNIT(3390) VOLUME(volser)
where volser is a non-SMS volume

back to top

Replacing a lost or damaged ML2 tape

Hopefully, you duplex your ML2 tapes? First, identify the alternate volume with the command

  HSEND LIST TTOC (volser) DSI TERM

Then, check from the TTOC listing that this tape is not part of a spanned set. If it is, find the spanned dataset by running a LIST TTOC on the previous volume and recall the spanned dataset.
Check the 'link' is broken by repeating the LIST TTOC (volser) command for the original volume. It should now show no previous volume, but if it still does, alter the volume fields
For example

	E09915 - original volume
	E00844 - alternate volume
	E08894 - previous volume

The fix command to break the link chain is

 HSEND FIXCDS T L2-E00844-0000 PATCH(X'18' X'4040404040')
      VER(X'18' X'C5F0F8F8F9F4')

And to delete the successive volume is

 HSEND FIXCDS T L2-E08894-0000 PATCH(X'1E' X'4040404040')
      VER(X'1E' X'C5F0F8F8F9F4')

You can then replace the broken cartridge with alternate one, with the command

 HSEND TAPEREPL ORIGINALVOLUMES(volser) ALTERNATEUNITNAME(esoteric)

where 'esoteric' is the correct tape unit for your alternate ML2 tapes

back to top


ML1 pool full

You could consider adding more volumes to the ML1 pool, you could empty out older data, or you could just move out the bigger files.
This command will move older data to ML2

 MIGRATE MIGRATIONLEVEL1 DAYS(3)

If automigration is active, this command will fail with

 ARC0515I COMMAND LEVEL-1-TO-LEVEL-2 MIGRATION NOT PERFORMED, AUTO 
 ARC0515I (CONT.) LEVEL-1-TO-LEVEL-2 MIGRATION IS RUNNING          
 ARC1000I VOL=*LEV1 MIGRATE PROCESSING ENDED                       

The following job, supplied by Allan Fuller, will pick out and move the 30 biggest files.

//'your job card'
//***** 
//*****  MOVES 30 LARGEST DATASETS FROM ML1 TO ML2
//***** 
//STEP0001 EXEC 'your SAS program' 
//SASLOG   DD SYSOUT=* 
//SASLIST  DD SYSOUT=* 
//MCDS     DD DSN='your HSM MCDS',DISP=SHR
//CLIST    DD DSN=&&TEMP,UNIT=DISK,DISP=(,PASS,DELETE),
//         SPACE=(80,(30,1)),AVGREC=U,RECFM=FB,LRECL=80,DSORG=PS
//SYSIN    DD *      
   DATA FILE2 (KEEP = DSNAME TRK_USE); 
          INFILE MCDS ; 
          INPUT @47 RECTYPE £1. @;
          IF RECTYPE = '00000000'B ;  * 00/D *;
          INPUT @1 DSNAME £44.
                @71 FLAG PIB1.
                @121 BLK_USE PIB4. ;
          IF SUBSTR(DSNAME,1,10)= 'Z999999999' THEN DELETE;
          IF FLAG = '.....0..'B ;  * LEVEL 1 SEARCH *;
          TRK-USE=BLK_USE/23;
        IF TRK_USE>200 ;
       *;
 PROC SORT DATA = FILE2;
 BY DESCENDING TRK_USE;
 DATA _NULL_;
 SET FILE2;
 FILE CLIST NOTITLES;
 M=-1;
 PUT @1 " HMIGRATE '" DSNAME + M "' ML2 /*" TRK-USE '*/';
 *;
 IF _N_=30 THEN STOP;
 RETURN;
/*
//STEP0002 EXEC PGM=IKJEFT01
//SYSPRINT DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
//SYSTSIN  DD DSN=&&TEMP,DISP=(OLD,DELETE)

TEST this program before you use it at your site.

back to top

SDSP Datasets full

This job will migrate the biggest files from the SDSPs. Remember, the SDSPs are VSAM KSDS files. They can appear to be full, but still have lots of free space inside them. Migrating files will not make them look empty, unless you migrate the records with the highest keys.

//'your job card'
//* MOVES 250 LARGEST SDSP DATASETS FROM ML1 TO ML2
//STEP0001 EXEC 'your SAS program'
//SASLOG   DD SYSOUT=*
//SASLIST  DD SYSOUT=*,OUTLIM=600000
//MCDS    DD DSN='your HSM MCDS',DISP=SHR
//CLIST    DD DSN=&&TEMP,UNIT=DISK,DISP=(,PASS,DELETE),
//         SPACE=(80,(30,1)),AVGREC=U,RECFM=FB,LRECL=80,DSORG=PS
//SYSIN    DD *
   DATA FILE2 (KEEP = DSNAME TRK_USE);
          INFILE MCDS ;
          INPUT @47 RECTYPE £1. @;
          IF RECTYPE = '00000000'B ;  * 00/D *;
          INPUT @1 DSNAME £44.
                @71 FLAG PIB1.
                @121 BLK_USE PIB4. ;
          IF SUBSTR(DSNAME,1,10)= 'Z999999999' THEN DELETE;
          IF FLAG = '....1...'B ; * SDSP SEARCH *;
          TRK_USE=BLK_USE/23;
 PROC SORT DATA = FILE2;
 BY DESCENDING TRK_USE;
 DATA _NULL_;
 SET FILE2;
 FILE CLIST NOTITLES;
 M=-1;
 PUT @1 " HMIGRATE '" DSNAME + M "' ML2 /*" TRK_USE '*/';
 *;
 IF _N_=250 THEN STOP;
 RETURN;
 PROC PRINT DATA=FILE2;
 RUN;
/*
//STEP0002 EXEC PGM=IKJEFT01
//SYSPRINT DD SYSOUT=*
//SYSTSPRT DD SYSOUT=*
//SYSTSIN  DD DSN=&&TEMP
,DISP=(OLD,DELETE)

TEST this program before you use it at your site.

back to top

RECALL failures on ML1 volumes

  1. List dataset using TSO 3.4 and issue HLIST DSN(/) MCDS TERM to find the migration volume, migration date and SDSP (if used)
  2. Look at migration volume via TSO 3.4 to find HSM name, using migration date to find Innnn (where nnnn is the julian date)
    Note: HSM name will be HSM.HMIG.Tnnnnnn.xx.yyyyyy.Innnn where Tnnnnnn is the migration time backwards
  3. Issue HSEND FIXCDS D / DISPLAY ODS('HSM.HMIG. Tnnnnnn.xx.yyyyyy.Innnn')
  4. Issue HSEND FIXCDS A / DISPLAY ODS('HSM.HMIG.Tnnnnnn.xx.yyyyyy.Innnn')
  5. Run an IEHLIST to print a dump of each record
  6. Run a DSS dump of HSM.HMIG. Tnnnnnn.xx.yyyyyy.Innnn
  7. After all diagnostics taken list dataset using TSO 3.4 and issue:
        
     HSEND FIXCDS D / DELETE to delete migration control record 
    
     HLIST DSN(/) MCDS TERM to check entry has been deleted
    
     DELETE / NOSCRATCH to delete catalog entry
    
  8. Try to recover data from a backup

back to top

HSM locking out a batch job creating a GDG

I have seen problems with DFHSM locking out production batch when that batch job was trying to create a +1 GDG. By default, HSM will ENQ on the base GDG catalog entry while migrating an individual file. This means if a batch job comes along and wants to create a (+1) version then that job is locked out until the migration is complete as it cannot update the catalog. It is common these days to see very big GDG files; 3-4000 cylinders is not unusual, and it can take half an hour or more to migrate such a big file. There appears to be three options to fix this; just wait for the catalog to free up, set problem GDGs to never migrate or ask your developers not to create big files. None of these options are really acceptable.

There is another solution, which is to apply an HSM fix to change it so it just ENQs on the one file that it is migrating. To do this you apply the following patch, but read the caveat below first.

 HSEND PATCH .MCVT.+4C3 BITS(......1.) VERIFY(.MCVT.+4C3 BITS(......0.))


The seventh bit is 0 if enqueing on the base is desired and that is the default. It is 1 if no base enque is desired.

Caveat; if you do not enque on the base, and if HSM is migrating the oldest GDG at the same time a batch job is creating a (+1) version, then the job will get an IEC331I 042-006 error. This is because DFP needs to delete the oldest GDG and it cannot because the file is in use. The batch job will actually complete fine (assuming it gets no other errors), but the problem is that it leaves an orphaned file behind it that will never be cleaned up automatically. Eventually the GDG number will roll around and catch up again and a create will fail, so the best bet is to get automation to trap this message and raise a problem ticket.

The choice is yours, you can live with contention issues, or you can cope with having to manually clean up files from time to time.

back to top

Reclaiming tapes that are almost empty

As data expires from the HSM system it is logically deleted from the MCDS or BCDS, and marked as unwanted on the tapes. This effectively leaves 'holes' in the tape data that cannot be used. As time goes by, the tape will contain less and less valid data, but HSM will not release a tape for scratch until it is completely empty. This can be a huge problem if you have hundreds of tapes that are almost empty as that would be wasting tapes and library slots. The answer is to schedule regular RECYCLE commands to clear out partially used tapes. The command you need is

 HSEND RECYCLE ML2 EXECUTE PERCENTVALID(25)  

This will scan all the ML2 tapes and copy all data off tapes that contain 25% or less valid data. You can use the same command against BACKUP, or SPILL tapes, or simply specify ALL instead of ML2.

Another effective use of RECYCLE is to move old ML2 data to a new tape library. Suppose you have an old set of ML2 tapes with volsers between A00000 and A99999. To move the data to a new set of tapes you could use the RECYCLE command

HSEND RECYCLE A  EXECUTE SELECT(INCLUDE(RANGE(A00000:A99999))) PERCENTVALID(100)

This command limits RECYCLE to a specific range of tapes, and the PERCENTVALID(100) will clear out all of them.

On similar lines, old backups are not expired automatically. You need to schedule a

 HSEND EXPIREBV EXECUTE

command regularly or HSM will not even logically delete backup data.

back to top

Processing empty datasets

DFHSM will backup and recover empty datasets with no problems, but it has trouble migrating empty files. If you want to allow DFHSM to migrate empty datasets you need to add the following patch to your ARCCMDxx HSM initialisation dataset in SYS1.PARMLIB.

 
PATCH .MCVT.+3D5 BITS(1.......)

When field MCVTFMV0 is set to 1 DFHSM will not check for empty datasets, or BLKSIZE=0.

back to top

Recovering a recalled file from HSM

If you recall a dataset, then delete it straight before the next backup run, you may have lost it. This often happens when an older GDG has rolled off. In some instances it may be possible to recover a dataset from a HSM migrated copy, if that dataset has been recently recalled. If the data was on an ML2 tape, the data is intact until the cartridge is RECYCLED. If the data was on ML1, the ML1 dataset entry will be deleted upon completion of the RECALL, but is restorable, using the standard file restore procedures, provided you back up your ML1 volumes. You need an HSM D record (migrated dataset record) for the recovery, and this may or may not exist.

The process requires that you run some report jobs on a daily basis, the details are in the link below

This procedure was supplied by Robin Lowe, and has the following steps :

Pre-requisite report jobs



          Does the D record Exist?
             /                   \
	   YES                    NO
	    |                     | 	
         Was the file        Find the D record info
          on ML2?                         |
         /               \                 was the file 
       YES             NO	             on ML2?
        |                     \                /         \	
Reset the D record  \          NO	        YES
        |                        \        /	            \	
  recall	  is there an ML1 backup?        \
  the file             /         \          Has the ML2 tape been recycled?
                     YES          NO 	          /       \
                      |                 \                 /          \
                      |                  \              YES          NO
         Restore the ML1 file  \             /             |
                      |                     \          /	     |
                      |                 sorry, you've           | 
                      |                 lost the data            |
                       \                                               /
                        \                                             /
                          ----  Rebuild the D record ---------
                                          |
                           Define the migration catalog entry
                                          |
                                   Recall the file	

 

back to top


Cookies Policy: This site does not use cookies to gather personal data.                                                                                                                                   © 2014 Lascon Storage
See the Privacy section for details