HSM Tape and Dataset tips

Recall failures on large datasets
Replacing a damaged ML2 tape
Recall failures on ML1 datasets
Empty dataset processing
GDG contention
Reclaiming tapes that are almost empty

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                       

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

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. If a tape is part of a connected set, then every tape in the connected set must have 25% or less data on it for this command to work.

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

GDG contention

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 those migrates can take half an hour or more. 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.))

{0 if enqueing is desired (default) 1 if no enqueing is desired}

Caveat; if you do not ENQ 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

Copyright © Lascon Storage Ltd. 2000 to present date. By entering and using this site, you accept the conditions and limitations of use