Forum Discussion

thesanman's avatar
thesanman
Level 6
15 years ago
Solved

scratch pool Java Console bug?

Here's one that bit me overnight; luckily I picked it up.  Essentially my scratch pool lost the "scratch pool" tick!

Using the Windows Java Console Click to Media and Device Management > Media > Volume Pools

All of your volume pools are listed; pay specific attention to the scratch pool and the column "Scratch" which should read "Yes".

Double click on "Scratch" in the right hand Volume Pools panel to bring up the Scratch pool properties box. The Scratch Pool should be ticked.  Click "Ok" which will close the box and then watch the Scratch column against the scratch pool?  Does it still say "Yes" or does it change to "No" despite you having not changed it!

Mine changes to "No"!

Do it again, the properties box comes up but the scratch pool box is still ticked and click ok. The scratch column goes back to "Yes"

I've seen this twice here when I now suspect someone has inadvertantly opened the scratch pool properties and clicked Ok to close it. Of course, the next time NBU wants a scratch tape there aren't any because the scratch pool isn't ticked as "scratch".

Obviously you should "cancel" the box if you accidentally open it but if you "Ok" it … a little time bomb waiting to bite you.

Does it do under v7?  In my case it happens under v6.5.5 but I also think back and it probably happened under v6.5.3 as well.

I've yet to log a call; but suspect I will in the morning.

  • Missed by .1; my call to Symantec says it's fixed in v6.5.6 ... I can neither confirm or deny this as I haven't got a v6.5.6 setup handy.

    Can anyone confirm it's fixed in v6.5.6 or for that matter v7?
  • but supposedly fixed in 6.5.5!!!

    http://seer.entsupport.symantec.com/docs/323377.htm


    ***EDIT***
    Are you running 6.5.5 Java Console? If so may be worth speaking to Support to see if an EEB is available.
  • I have a script I run from cron several times a day that checks the number of scratch tapes and emails the count to my operations group - so they can watch it, I added this line to it:

    /usr/openv/volmgr/bin/vmpool -set_scratch scratch_pool

    This will reset your scratch pool to "scratch_pool" obviously you would need to change it to match your scratch pool name.

    This will overcome any inadvertant updates caused by the bug.

    funny - they never called me to tell me about any updated binaries to fix this...

  • Thanks for this.  Your supplied link didn't show up in my search.  I will log a call tomorrow. 

    EEB or not; it's just as important for me to ensure our Operations and Support staff understand the issue so they don't inadvertently toggle the scratch pool to "No".  If an EEB is available it's a bit of a task to get it rolled out .

    Thanks,
    Malcolm
  • Missed by .1; my call to Symantec says it's fixed in v6.5.6 ... I can neither confirm or deny this as I haven't got a v6.5.6 setup handy.

    Can anyone confirm it's fixed in v6.5.6 or for that matter v7?
  • Sorry I'm late!  :)

    This fix was included in 6.5.6 - it's listed under ET1600230 on page 36 of the 6.5.6 Release Notes:

    Veritas NetBackup 6.5.6 Release Update Readme
     http://support.veritas.com/docs/341279

    And this bug is not in the 7.0 line at all.

    We'll correct TechNote 323377.
  • Finally got around to checking this in v7 and yes, it's fixed there.