🚀 go-pugleaf

Greetings - we recently upgraded to vmtape 1.3A and are unhappy with the
change to how scratch tapes are handled on the picklist.  Previously when a
"scratch" was run the pointer was reset and the entire scratch pool appeared
as if it was sorted in (alphabetical/numerical) order.  This allowed us to
keep certain tape groupings out of circulation because they would appear
further down on the list but still be available as scratch tapes from the
general pool if need be.  We also have certain series(es) dedicated to
software/service tapes and these tapes are not always physically present to
be used when in scratch status.   Also it allowed multiple scratch tapes to
be selected from basically the same area (eg. cr0004, cr0006, cr0010) rather
than from scattered locations thru-out the entire tape library.  The new
release of vmtape appears to append tapes scratched in a scratch run to the
end of the picklist  and maintain the "pointer to next tape" where it had
left off, in effect forcing the autopick for scratch tapes to cycle thru the
entire scratch pool before reusing the more recently scratched tapes.  i
contacted Sterling Software and they basically said, "yep, that's how it
works now" and "no, you can't override it" altho they did relate that i
wasn't the first customer to call about the issue.

i sorta understand the intent is to more evenly distribute scratch tape
utilization but it's short term effect here has been to disable the autopick
feature for scratch tapes and now has our operators selecting scratch tapes
from a paper list.  Anyone else out there run up against this ?
Any suggestions for possible solutions, creative or otherwise ?

Thanks,
                   greg nyce - West Chester University, PA - gnyce@wcupa.edu
 - (610) 436-1069