Fuddin, I would say, the data set was allocated before TEMPDSN was activated. Recommendation is to IPL after activation, did you? I can imagine problems together with rolling IPL along the Sysplex in a HA environment. So check whether you need to restart certain applications independent from IPL. As far as I remember there was an issue with SYS1 RACF profiles because before the year 2010, temporary data sets started with prefix 'SYS0' in HLQ. You might want to check your DATASET profiles and global access checking tables in RACF.
We activated TEMPDSN about 18 months ago together with IPL. We are very happy with it, almost no problems. We had exactly one issue with a single ISV product. They had a somewhat strange constellation: An STC is started with an STC user which invokes an ISPF session under a second user (TSO user). A temporary file is allocated by this TSO user. That TSO ASID is afterwards stopped by the STC user with MVS STOP command instead of logoff by the TSO user. From my understanding, the ISV had to change their EXITRTN accordingly in order to remove the temporary data set during MVS exit processing by the still logged on TSO user. The ISV never told me details about what happened, but my understanding was (may be I am totally wrong): The STC ASID created a new TCB to allocate the temporary data set *before* a third TCB for the ISPF session was created -- both with ACEE for the TSO user. Then, the TCB for file allocation was terminated and the TCB of the ISPF session ran with an ACEE different to that of the STC ASCB. Nota bene, the temporary data set is bound to the STC's JFCB. During termination of that ISPF session, the temporary data set was not removed. No problem, the JFCB is still ok. But at termination of STC, JES cleans up and the STC user is not allowed to delete the temporary data set referenced by the JFCB. So, carefully revise your environment. And as so often: it is more interesting what you are *not* doing. In our case the cause of the problem was not deleting the temporary data set by the user which allocated it. And this is not a problem of TEMPDSN but a problem of the application logic. Activating TEMPDSN was only finding this error. Cheers Michael Von: fuddin <[email protected]> An: [email protected] Datum: 2011-06-09 07:26 Betreff: TEMPDSN Activated Gesendet von: IBM Mainframe Discussion List <[email protected]> Dear Listerner, z/Os 1.9 runing z10 machine. Few week ago I have activated this TEMPDSN class. Today I face this error but only for certain ID. If anybody have the same problem? Thanks in advance for sharing. Below is the error: ICH408I USER(xxxxxx ) GROUP(SA ) NAME(xxxxxx ) 168 SYS11160.T110153.RA000.xxxxxx.SORTDK03.H01 CL(DATASET ) VOL(nnnnnn) INSUFFICIENT ACCESS AUTHORITY ACCESS INTENT(ALTER ) ACCESS ALLOWED(NONE ) IGD17061I INSUFFICIENT SECURITY AUTHORIZATION FOR 169 DATA SET SYS11160.T110153.RA000.xxxxxx.SORTDK03.H01 ON VOLUME nnnnnn HISTORIC RETURN CODE IS 8 DIAGNOSTIC INFORMATION IS 04130400 IEF453I xxxxxx - JOB FAILED - JCL ERROR - TIME=11.19.21 $HASP395 xxxxxxx ENDED 2011-06-09 Thanks And Regards, ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
