On 06/28/2010 02:07 PM, Juan Mautalen wrote: > Hi: > > We are at z/OS 1.9 > > Recently, "Tape Data" protection was changed (from volume level based on > TAPEVOL class to DSN level). > > Relevant settings of the OLD schema: > - RACF TAPEVOL class ACTIVE > - TAPEDSN INACTIVE in SETROPTS > - TAPESECURITY(RACF) specified in DFHSM Parmlib. > - TPRACF(N) in DFRMM > - No tape security options etablished in DEVSUPxx member of SYS1.PARMLIB > > Relevant options of the CURRENT schema: > - RACF TAPEVOL class INACTIVE > - TAPEDSN INACTIVE in SETROPTS > - TAPESECURITY(EXPIRATION) specified in DFHSM Parmlib > - TPRACF(N) in DFRMM > - Options TAPEAUTHDSN=YES and TAPEAUTHF1=YES in effect via DEVSUPxx > member of SYS1.PARMLIB > > After implementing the new security options and checking for several days > that the new schema was working fine, as a RACF administrador i Inactivated > TAPEVOL class and deleted ALL its profiles (including DFHSM multivolumes > named DFHSMx, with x=0,1,....9). > > From that moment, the following behaviour is observed: > > When DFHSM finishes recycling a volume it tries to remove its RACF protection > (because of TAPESECURITY(EXPIRATION) setting). However, given that the > protection was already deleted, the action fails and the following error > message is written to DFHSM Joblog: > > ---------------------------------------------------------------------------------------------------------------- > STC01002 ICH408I USER(HSMUSER ) GROUP(DFHSM ) NAME(DFHSM ) > 152 > X62021 CL(TAPEVOL ) > > DELETE - RESOURCE NOT FOUND > > STC01002 ARC0359I ERROR REMOVING TAPE VOLUME X62021 FROM 153 > > ARC0359I (CONT.) DFSMSHSM'S RACF TAPE VOLUME SET, RC=20, REAS=4 > ----------------------------------------------------------------------------------------------------------------- > > > Moreover, we observe that DFHSM, even after the unsuccessfull deletion of > RACF protection for some volume, stills considers the volume to be RACF > protected and thus tries to remove its RACF protection each time it empties > it (as part of its recycling process). > This behaviour does not cause any operational problem in DFHSM, but we want > to get rid of these error messages that, if nothing is done, will last > forever. > Question: > How can we indicate to DFHSM that its volumes are not RACF protected anymore, > or that it should not worry about removing their RACF protection? > Thanks in advance for your help, > > JUAN MAUTALEN ...
Although we now protect most tapes by DSN, we left the TAPEVOL class active and still allow DFHSM to specially protect its own volumes. We also find it useful sometimes to use TAPEVOL to allow access to specific labeled off-site tapes that contain file names that conflict with our installation naming conventions. -- Joel C. Ewing, Fort Smith, AR [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
