REPORT DAILY FUNCTION

Ever had a wee look at the output from a 'HSEND REPORT DAILY FUNCTION ODS('YOUR.DATASET')' ?

I want to use todays post to rant a bit about the values presented here. As you see in the picture , I have boxed some of the values with a very nice red box :)

After reading my rant about these (fictive) figures feel free to leave your comments.

This might very well be the first in a series of 'how do I rate my figures'. So without further ado, here's my 2cc on the matter.....

Average Age. For the migrates and the recalls it's quite nice to be knowing what the average age is. Low values in the 'recall' rows might indicate HSM thrashing (recalls just after a migrate). The values in the 'migrate' rows must match your gut feeling in the average setting for migrates. (14 days Ml1, 30 days Ml2 or whatever your shops guidelines are).

Average Queued Time. Now this is an odd figure to be interpreting. It represents te amount of time an average request was held up in the queue. It's the average amount of time a request to recall a ML2 dataset was not served by HSM. Generally speaking: if it's high (> 120secs is my RoT atm) you've got more request coming in than HSM may/can handle. This might be due to SETSYS TAPEMAXRECALLTASKS, the available units or can even be due misuse :)

User Initiated Backups. Another nice figure to determine user behaviour. I've seen reports where every monday 400 userbackups were being made. User migrates are another thing to look at. Then it's the hunt for Red October, or whatever the user is doing these actions. The art of trying to find out why they are doing this, without assuming it's a wrong thing to be doing is a tricky but fine one. Remember, user migrates cause partial tapes!

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.