Article View: bit.listserv.l-vmctr
Article #730Re: vmtape command mode - cms prefix
From: Ed Rovera
Date: Thu, 28 May 1992 21:36
Date: Thu, 28 May 1992 21:36
42 lines
2898 bytes
2898 bytes
On Thu, 28 May 1992 15:53:05 EDT Mike Ramundo said:
>...
>
>( what I'd really like to be able to do is to erase files
> CPOOL000 PICKLIST and RPOOL000 PICKLIST after initialization and
> after every REFRESH POINTER - ie no scratch tapes available unless
> a pool is specifically requested, the pool exists, and the user is
> authorized to access the pool ) ie, any tape not assigned to a pool
> must be mounted by a request for a specific volser. 'SCRTCH' would
> not be valid unless a pool name was specified because the 'default'
> pools would always be empty/nonexistent.
If you have OPERATOR authority in the VMTAPE CONFIG file you can
issue:
VMTAPE CMS ERASE fn ft fm
and 'fn ft fm' will be erased. I have no idea what damage you might
inflict on VMTAPE by having it erase one its PICKLIST files, but you
can certainly erase it if you want.
Why not take the tapes you don't want people to use and assign them
to a pool that you don't authorize anyone to pull from? We did this
when we were migrating from VM/SP to VM/XA. About 200 carts were
'reserved' for VMTAPE in XA so I just assigned them to a pool called
SAVEXA and then I specified bogus DSN= and JOB= fields in the ASSIGN
file. This way, VMTAPE in SP knew the tapes were there and would show
them in all our reports but wouldn't let anyone mount them. The exact
opposite was done in the VMTAPE TMC in XA; the vast majority of the
carts in the VM library were assigned to a bogus pool and no one could
mount them in that system. VMTAPE in XA could use only the 200 or so
carts that were not in that holding pool. Doing this allowed us to
avoid the possibility of the XA system trashing live data from the
production side of the shop while still being able to account for all
tapes in either system. It also eliminated CPOOL000 completely!
Maybe your goal is not to just have a reserved pool of tapes, but
from your description, I think this might work for you.
- Ed Rovera
UCSF ITS Division
415-476-3119
Technical Details
Message-ID:
<L-VMCTR%92052818015269@VM1.CC.UAKRON.EDU>Path:
arc1-ca.pugleaf.net!sparky!uunet!uvaarpa!darwin.sura.net!paladin.american.edu!auvm!UCSFVM.BITNET!EJR9006Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fe320,43df814d15b6301,start X-Google-Attributes: gidfe320,public X-Google-ArrivalTime: 1992-05-28 01:23:50 PST Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Path: arc1-ca.pugleaf.net!sparky!uunet!uvaarpa!darwin.sura.net!paladin.american.edu!auvm!UCSFVM.BITNET!EJR9006 Message-ID: <L-VMCTR%92052818015269@VM1.CC.UAKRON.EDU> Newsgroups: bit.listserv.l-vmctr Date: Thu, 28 May 1992 14:36:40 PDT Sender: VMCENTER Components Discussion List <L-VMCTR@AKRONVM.BITNET> From: Ed Rovera <EJR9006@UCSFVM.BITNET> Subject: Re: vmtape command mode - cms prefix In-Reply-To: Message of Thu, 28 May 1992 15:53:05 EDT from <SYSMRR@ALBNYVM1> Lines: 42