Resize (or move) DfRMM Journal Dataset

Ever wanted to resize the RMM Journal dataset? Ever wanted to do this without stopping RMM?

This is the short recipe for doing so:

1. Allocate your new journaldataset (DFRMM.NEW.JOURNAL)
2. Quiesce DFRMM (f DFRMM,quiesce)
3. Run EDGHSKP, PARM=(BACKUP) to empty the Journal
4. Rename current journaldataset
5. Rename DFRMM.NEW.JOUNRAL to whatever is in your EDGRMMxx (or change EDGRMMxx)
6. Restart DFRMM (f DFRMM,m=xx)
7. Be a good boy and delete the old journaldataset

For calulating the required size of your journal dataset you can use the formula from the Implementation and Custumization Guide:

• 1.5 KB for each user change made
• 1.5 KB for each data set retained by a vital record specification
• 1.5 KB for each data set no longer retained by a vital record specification
• 1.5 KB for each expiring volume
• 6.7 KB for each specific mount
• 8.3 KB for each scratch mount
• 1.5 KB for each volume retained by a vital record specification
• 2.6 KB for each volume in or out of the library
• 3.0 KB for each volume returned to scratch
• 3.5 KB for each volume moved to or from a storage location
• 1.5 KB for each volume that has not reached its expiration date and is no longer retained by a vital record specification
• 1.5 KB for each logical volume exported or imported
• 1.3 KB for each vital record specification created

My RoT when resizeing the journal dataset is to just triple the size, as changes regarding the tape environment are mostly not reflected in the sizing parameters of the journaldataset :)

To make this a complete HOWTO, below you will find the JCL to backup the journal when DFRMM is not active.... (dots inserted for readability)

//STEP EXEC.. PGM=EDGBKUP,
//............PARM='BACKUP(DSS)'
//SYSPRINT DD SYSOUT=*
//MASTER...DD DISP=SHR,DSN=YOUR.CDS
//JOURNAL..DD DISP=SHR,DSN=YOUR.OLD.JOURNAL
//JRNLBKUP.DD DSN=YOUR.JRNLBKUP
//............DISP=(,CATLG),
//............AVGREC=U,SPACE=(9000,(500,500)),
//............LRECL=9000,RECFM=VB

HSM in a Virtual Tape Environment - Part 1

To have HSM create its (his? her?) backups, migates and dumps in a virtual tape enviroment some issues regarding tape recycling have to be addressed.

Because tape is virtual, the old-skool need for recycle (free up tapes!) is no longer as valid as it was, as the amount of tapes is a multitude of the amount one had in a physical environment. Virtual tapes however are not limitless, and one should keep the amount of tapes HSM 'manages' in repectable quantities.

Major drawbacks on the HSM recycle in a virtual environment is the immense negative impact this 'housekeeping-task' has on the cache on the virtual tape environment. This is even a bigger issue when one has more than only HSM as an exploiter of the VTS.

Ideally one would want to only recycle the empty tapes (percentvalid = 0). In order to get some isight in the the 'príce' one has to pay for this (via a higher tape consumtion by HSM) one should look at the following figures:

• number of tapes being used from the scratch pool each day
• how many of these are HSM
  
• life cycle for your non-hsm tape data
  
• life cycle for your hsm data (mostly dependent on life-cycle for original data)
  (some parameters influencing this are RETAINDAYS ONLY BACKUP, RETAINDAYS EXTRA BACKUPS, PRIMARY DAYS, LEVEL 1 DAYS)
• number of tapes being freed by (daily/weekly?) recycle tasks
• Valid Data Distribution on HSM datasets (pctvalid from LIST TTOC) (=trigger for recycle)
  
• Valid Data Distribution on HSM tapes (this is *not* pctvalid from TTOC) a tricky value in a VTS environment
  

The nest part of this post will address how all these values will provide the information needed to tweak HSM (and maybe even the VTS) to reduce the negative impact of HSM in a VTS as much as possible.

VTSSTATS in SAS

For years I have been working in a shop where VTSSTATS (from IBM) was the MO for creating reports for the PtP VTS. After swithching jobs I came to work in a place where raw smf data was not kept.

This was a shock. However the alternative was so much nicer ; SAS. At first I hated the bitch but within months I started to love her (cue Guns n Roses music lol).

Anyway. After some time of getting to understand the basics of SAS, and the power it unleashes I started to create a VTSSTATS based on SMF94 records in a SAS DB. For one it is awesome in creating graphs. One of the best things is the little amount of effort needed to create animated graphs.

As a cliffhanger so you'll be back to get the full source download, here is one of the animated graphs. For those of you familiar with the graphs, its an animated version of the Active Data Distribution.

The reports are quite similar to the ones I origingally used from the VTSSTATS and VTSANAL94.xls but here is the complete list of graphs created :

• 01-VirtualMountsD1.gif.


• 02-VirtualMountsD2.gif


• 03-VirtualMountsDailyD1.gif


• 04-VirtualMountsDailyD2.gif


• 05-CacheReadWritesC.gif


• 06-CacheReadWritesD1.gif


• 07-CacheReadWritesD2.gif


• 08-StackedVolumesC.gif


• 09-BackstoreCapacityD1.gif


• 10-BackstoreCapacityD2.gif


• 11-VirtualMountTimes.gif


• 12-VirtualMountTimesH.gif


• 13-CacheMisses.gif


• 14-TotalDailyPhysMounts.gif


• 15-TotalDailyPhysMountsD1.gif


• 16-TotalDailyPhysMountsD2.gif


• 17-AveragaDailyPhysMounts.gif


• 18-AveragaDailyPhysMountsD1.gif


• 19-AveragaDailyPhysMountsD2.gif


• 20-AveragaDailyPhysMountsD1.gif


• 21-AveragaDailyPhysMountsD2.gif


• 22-DailyAverageMissTime.gif


• 23-HourlyAverageMissTime.gif


• 24-TotalAccessorMounts.gif


• 25-AvgAccessorMounts.gif


• 26-MaxConcPhysMounts.gif


• 27-MaxConcVirtMounts.gif


• 28-AvgThrottlingDayD1.gif


• 29-AvgThrottlingHourD1.gif


• 30-WritThrottDayD1.gif


• 31-WriteThrottHourD1.gif


• 32-OverallThrottDayD1.gif


• 33-OverallThrottHourD1.gif


• 34-CachTimesHourlyD1.gif


• 35-CachTimesDailyD1.gif


• 36-CachTimesHourlyD2.gif


• 37-CachTimesDailyD2.gif


• 38-MountedTimeDC.gif


• 39-MountedTimeHC.gif


• 40-DataToBeCopied.gif


• 41-DataDistributionD1.gif


• 42-DataDistributionD2.gif
  

HSM LIST TTOC

Here's the challenge:

Take the output from one (or more) HSM LIST TTOCs and store them in a SAS PDB keeping date and time the TTOC as made.

For this example we will only store a limited number of fields from the HSL LIST TTOC output, I assume you can fill in the blanks if needed :)

Without further ado, here's the SAS code:

First, we need to parse the entire input file (yes this can be a GDG base of the GDG containing all your LIST TTOCS!) (blogger still dont do blanks for me, so code has been downgrades with spaces for readbility)

data hsm01;
.. infile hsmttoc;
.. input @31 selstring $16.
.... @75 theDate $8.
.... @63 theTime $8.
.... @95 theSyst $8.
.... @1 VOLSER $7.
.... @19 TYPE $7.
.... @46 PCTVALID $4.
.... @101 LIBNAM $9.;


Next we wat to 'save' the time and date from the LIST TTOC HEADER.

data hsm02;
.. set hsm01;
.. if selstring = "TAPE VOLUME TTOC" then do;
.... call symput('saveDate', thedate);
.... call symput('saveTime', thetime);
.... call symput('saveSyst', thesyst);
.. end;
.. theDate = symget('saveDate');
.. theTime = symget('saveTime');
.. theSyst = symget('saveSyst');

Now we can drop all the unwanted lines, I took the lines with the LIBNAME as valid lines. I assume you know what value to use for libnam ;)

data hsm03(drop= selstring libnam);
.. set hsm02;
.. where libnam = 'YOURLIBNAM';

And there we have it, a nice collection with all HSM owned volumes, their type (backup, migrates dumps) and their percentvalid.

Still to do, or why this problem arised in the first place, complete the SAS job so we will end up with a nice 'active data distribution'-graph.

This is something for next time :)