Bob, You do now have a very good understanding of how RMM is working with
RACF to secure and validate tape volumes and data sets.
As far as I can see, if you do not have TAPEVOL active
- you lose any ability to control the use of BLP. This BLP authorization
is only performed today if TAPEVOL is
:[EMAIL PROTECTED]
Sent: Monday, March 13, 2006 5:06 AM
To: IBM-MAIN@BAMA.UA.EDU; Robert Hansel
Subject: Re: discrete profiles for tape protection.
Bob, To build on to what Russell has said..
In rmm you force all tapes to be rmm managed by including
REJECT ANYUSE(*)
in parmlib. Now to bypass rmm
John, The function performed by the RMM TPRACF options depends on how you
have RACF set up. If you were to inactivate TAPEVOL class rmm stops
creating and deleting TAPEVOL profiles for you.
With z/OS 1.8 we provide another option for TPRACF that will stop creation
of profiles but enable deletion;
, March 11, 2006 2:57 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: discrete profiles for tape protection.
Mike,
Your comments about running without TAPEVOL and/or TVTOC raises the
following issue. It is my understanding that with RMM the only way to
protect against unauthorized access to a tape
-Original Message-
Date:Thu, 9 Mar 2006 13:17:19 -0600
From:Mike Wood [EMAIL PROTECTED]
Subject: Re: discrete profiles for tape protection.
John,
You do not give any details about your setup of rmm and RACF, but I
I'm not sure if my question on this went out or not. Through many trials
I was finally able to get a job to abend after writing virtual tapes. The
only way I was able to do this however was to use a file that was on tape
already and it was using the fat tape 200gb. So I'm not sure if the error
On 3/9/2006 8:25 AM, John Benik wrote:
I'm not sure if my question on this went out or not. Through many trials
I was finally able to get a job to abend after writing virtual tapes. The
only way I was able to do this however was to use a file that was on tape
already and it was using the fat
John,
You do not give any details about your setup of rmm and RACF, but I
would guess that you are using rmm parmlib option TPRACF(P) or TPRACF(A).
It is very likely that it is rmm creating the TVTOC and the first data set
gets added either by OPEN issuing RACROUTE in DATASET class or by rmm
you were exactly right TPRACF(A). It sounds like the only way to avoid
this is to not use Tapevol any longer, is there something else I should
change the TPRACF(A) to?
--
For IBM-MAIN subscribe / signoff / archive access
On 2/26/2006 1:12 PM, John Benik wrote:
We have recently begun a tapecopy process from IBM VTS's to STK VSM's. We
have run into a few files that on the IBM side exceeded the max vol count
for discrete profiles, but when trying to copy them to STK there is an
issue and the discrete profile only
We have recently begun a tapecopy process from IBM VTS's to STK VSM's. We
have run into a few files that on the IBM side exceeded the max vol count
for discrete profiles, but when trying to copy them to STK there is an
issue and the discrete profile only allows them to go 42 volumes. On the
IBM
To: IBM-MAIN@BAMA.UA.EDU
Subject: discrete profiles for tape protection.
We have recently begun a tapecopy process from IBM VTS's to STK VSM's. We
have run into a few files that on the IBM side exceeded the max vol count
for discrete profiles, but when trying to copy them to STK there is an
issue
Hi,
The DFSMSrmm observation I feel might be worth considering, as per the
z/OS V1R7.0 DFSMSrmm Implementation and Customization Guide (dgt2c840)
manual. Section 11.9.1 Recommendations for Using RACF Tape Profile
Processing states:
1. The maximum number of entries for data sets that a TVTOC can
13 matches
Mail list logo
