If I read the alert from CA properly they do not recognize a 2010 TEMPDSN properly otherwise all would be fine.
The workaround is to add specific rules for the 2010 TEMPDSN dataset name format to allow access to all users. Top Secret does allow a SYS1 (no dot) as a valid generic dataset prefix -----Original Message----- Mark Zelden On Wed, 2 Dec 2009 07:58:20 -0600, McKown, John <john.mck...@healthmarkets.com> wrote: >> -----Original Message----- >> From: IBM Mainframe Discussion List >> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ken Porowski >> Sent: Tuesday, December 01, 2009 4:19 PM >> To: IBM-MAIN@bama.ua.edu >> Subject: Re: Date / Time simulation? >> >> 2010 may be bad enough >> >> Temporary dataset names will begin with SYS10ddd >> (SYSyyddd.Thhmmss.RAnnn.jobname.Rnnnnnnn) >> >> Depending on your security software (RACF, ACF2, Top Secret) and your >> specific rules the "SYS10" could fall under rules meant for SYS1 >> datasets which are hopefully well protected. >> >> CA issued an alert for Top Secret users, not sure about RACF or ACF2. >> >> It's the kind of thing you would like to test in advance rather than >> getting a call just after midnight on 01/01/2010 when you're half >> blotto. >> > >I don't see how protecting SYS10 would affect SYS10ddd. Those are >separate HLQs. And, at least in RACF, you cannot "wild card" an HLQ profile. E.g. SYS1* is invalid in a RACF profile. You'd have SYS1.* or SYS1.** or ... . I don't know either ACF2 or TSS. > >Also, IIRC (unsure), RACF somehow "knows" if a dataset is a temporary dataset or not in most cases and does not do any RACF processing on known "temporary" datasets. I remember this because somebody on the RACF forum was complaining about RACF rules affecting "temporary" datasets in some CA product. It turns out that the product was, somehow, generating a "permanent" dataset with a name that looked like a temporary dataset and RACF was failing that access. The fix was required to the product, not RACF. > It is true that temporary data sets don't need to be managed by RACF. However, you may want to via the TEMPDSN class. I don't recall when that was added (a long time ago), but there has been a health check for activating it since z/OS 1.9 I think. Here is doc from z/OS 1.2: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ichza710/7.9? ACTION=MATCHES&REQUEST=TEMPDSN&TYPE=FUZZY&SHELF=ICHZBK11&DT=200107101434 16&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK&S crollTOP=FIRSTHIT#FIRSTHIT You can protect DFP-managed temporary data sets. Normally, these data sets are considered protected from any accesses except by the job or session that created them, and therefore do not need to be protected by RACF. However, the following situations could leave a temporary data set unprotected: A system failure An initiator failure or initiator termination by the FORCE command An automatic restart--between the failure and the restart In these cases, if the TEMPDSN class is active, only users with the OPERATIONS attribute can scratch any residual DFP-managed temporary data sets remaining on a volume. Note: The user with the OPERATIONS attribute can access the data set only to scratch the data set. No other access is allowed (such as would be allowed by READ or UPDATE access authority to the data set). Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
