With our VTS, we found ourselves in the position where the default automatic DFHSM recycle was unable to keep up with scratch cartridge release that was needed to maintain the required scratch count, which was putting the whole VTS environment at risk (90+% of which was consumed by DFHSM migration). And VTS reclaim was also struggling to keep up (the MUCH more dangerous aspect), DFHSM recycle & VTS reclaim were pretty much running 24x7 trying to perpetually de-honeycomb the whole environment, and fighting a losing battle.
Hard to tell from your description whether you are asking this, because you are finding yourself in that position too. If you are, then it is a potentially solveable problem, but it aint straightforward, and do-ability and effectiveness may be heavily dependant on a very good understanding of your physical VTS arrangement (e.g. grid setup, virtual drive arrangements, etc.), and the ability to 'adjust things' where necessary. Reading the OCDS and determining the 'best' DFHSM recycle candidates is a good first step of that journey (to ignore any chained volumes, thus concentrating recycle focus on the lowest utilised singletons to free up), driving as many manual recycles as required. Depending on how dire a situation you are in, that may be enough by itself, but obviously manual recycles are single streamed, which is the slight downside, although you can mitigate that to a certain extent by spreading across multiple LPARs. On 2 March 2016 at 23:20, Anthony Fletcher <flet...@nz1.ibm.com> wrote: > We are using a VTS with the virtual tapes defined as 3490s, and we are > using the recommended 'Mark TAPE Full' option. That's all well and good. > It does, however, mean that there are a lot of 'tapes' and many of those > may have a mixture of valid and no-longer-valid data sets - a call for > Recycle. The VTS is probably under configured, but that's life, and its a > financial institution so they keep everything for 7 years, and are paranoid > about keeping things so there is really too much data floating around that > has to continue to float around. > > HSM can decide that it should do recycles, and if it does decide, then it > will according to its built in algrorithm. > > However, we find that the algorithm makes decisions based on the WHOLE set > of volumes that it knows about. That is OK, except that if there are a lot > of huge data sets that have been migrated, and they used full tapes (and > probably more than one tape). That skews the data to a higher than the > overall usage figure, and it doesn't conclude that recycles are needed. We > can of course initiate manual recycles but working out which ones to choose > is a pain. So we are looking at writing something to automate that. We are > looking at reading the OCDS and using that to select which volumes (eg > excluding the big ones) and then issue the RECYCLE commands. > > It seems that HSM ought to be able to automatically do the selection of > which volumes to do in a way that works for us. > > So the question is whether we can influence the recycle trigger point > automatically to select what to recycle? e.g. tell it to ignore the full > volumes and only assess based on the rest of the volumes or something like > that. > > We used to have real tapes and it didn't matter if the algorithm resulted > in few recycles, but with the VTS we need to release the space in the VTS > to stay alive. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
