🚀 go-pugleaf

I have been testing vmtape/e 1.3A and due to similar problems I will
probably recommend that we stay with 1.1 for the forseeable future.

A possible work around for most of the picklist-related problems I know
of would be 1) a change to the refresh logic to include a flag in the
pool definition as to whether or not a pool should be 'refreshed on
startup' and 2) the dynamic 'refresh pointer' command be changed to include
either a single specific poolname or the word ALL.

A config line(s) would be needed to set refresh/norefresh on 'default'
pools ( one for each device type ) (1)

                  - mike

(1) as a professional paranoid, I find the concept of a DEFAULT scratch
    pool frightening - NOTHING should be 'available for general use'
    unless specifically/deliberately placed in that status - it should
    NOT be a status things fall into if someone makes a mistake and
    forgets to include then in a specific pool.  We have only had one
    tape accidently overwritten here since we installed vmtape in the
    80's and I'd like to keep it that way.  In our current setup,
    vmtape's profile schedules a vmtlibr job to start seconds after
    initialization - the job does a cms erase of all default scratch pools