🚀 go-pugleaf

Just an 'off the top of my head' suggestion.  Most probably won't
like it due to their *site specific* needs, but, given the nature
and importance of data on our VMARCH tapes (how much importance do
you assign to student's Archived files of nudie GIFs, etc.?), since
we don't have the resources (system nor personnel) to do offsite
storage of data on VMARCH tapes, the following would meet our needs
without (or at least minimizing) all of the expected VMARCH/VMTAPE
headaches.

Setup a dummy frontend to VMARCH and run with two VMARCH IDs.  Have
everyone 'archive' to the frontend.  The frontend then actually Archives
(using the ASSIGN option) the file to the 'ONSITE' VMARCH ID and to the
'OFFSITE' ID.  The 'ONSITE' ID runs the way it does on all other systems
and so any problems stemming from offsite needs won't affect day-to-day
usage of the 'ONLINE' VMARCH ID. ie. no irate users yelling at you due
to your trying to adapt/meet your 'OFFSITE' needs.

The 'OFFSITE' ID closes off each tape as required by your sites needs (ie.
Daily, Weekly, etc.).  When the tape pool for the 'OFFSITE' ID starts to
run low on tapes, bring the tapes back onsite and then run a Merge/Purge.
Then send the M/P'd tapes back offsite.  If you have the resources to go
three months before having to do an 'OFFSITE' M/P, then you only end up
with a headache every three months.  Better that than having to worry
about HDR records, etc. on a Daily basis.

Given the volume of our Archive data, the number of tapes available, the
maximum size of any archived files, and other such factors, I could set
up a *non-impressive*, but *gets the job done* package, that would meet
*our sites* needs.  And, I know, the above would not meet the needs of
many sites, but it would meet ours.

Just some after lunch thoughts on a cold rainy day ...

Ron,,,