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 dataset by taking inappropriate advantage of tape label containing just the last 17 characters of the dsname (e.g., opening PAY.PROD.MASTER.FILE by calling it MYID.PROD.MASTER.FILE) is by implementing RACF TAPEVOL profiles with TVTOC and setting RMM option TPRACF to either (P) or (A). This causes RACF to keep track of the full dsnames on a given tape and guard against someone falsifying the name. Does RMM have other features or functionality that prevents misnaming tape datasets without involving TAPEVOL TVTOCs? Is yes, can you help me find the reference where it is described?
Thanks, Bob ------------------------------------------------------------------------ Robert S. Hansel | 2006 RACF Training RACF Specialist | > Intro & Basic Admin - Cinci., OH - JUN 6-7 RSH Consulting, Inc. | > Audit for Results - Boston, MA - MAY 23-24 www.rshconsulting.com | > Advanced Admin *NEW* - Boston, MA - MAY 2-4 617-969-8211 | See our website for details & registration form ------------------------------------------------------------------------ -----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 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 when the data set is closed. You could consider larger logical volumes sizes since VTS now supports this option, or you have to avoid the problem by not using both TAPEVOL class and the TAPEDSN option. Many people do use TAPEDSN without TAPEVOL. As long as you have tape management, and you do, you can consider running without TVTOCs, and most likely this means not using TAPEVOL. There are other considerations such as BLP and use of ustilities such as IEHINITT. Limitations such as this are just some of the reasons why we have previewed new tape data set security options in z/OS 1.8. http://www- 03.ibm.com/servers/eserver/zseries/zos/overview/zosnew18_preview.html Mike Wood RMM Development ---------------------------------------------------------------------- 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
