From: Ducky duke <[email protected]> Date: 03/25/2013 02:04 PM Hi all,
I have some temporary files not deleted. Seen with 3.4 with volume given. When i tried to delete them , i had an error message (entry not found) Listcat gave this : LISTCAT ENTRIES(SYS12048.T104505.RA000.IBMUSER.R0100008) IDC3012I ENTRY SYS12048.T104505.RA000.IBMUSER.R0100008 NOT FOUND IDC3009I ** VSAM CATALOG RETURN CODE IS 8 - REASON CODE IS IGG0CLEG-42 IDC1566I ** SYS12048.T104505.RA000.IBMUSER.R0100008 NOT LISTED Tried with IDCAMS DELETE : //STEP010 EXEC PGM=IDCAMS //DD01 DD DSN=SYS12048.T104505.RA000.IBMUSER.R0100008, // DISP=OLD,VOL=SER=WORK01,UNIT=3390 //SYSPRINT DD SYSOUT=* //SYSIN DD *,DCB=BLKSIZE=9040 DELETE FILE(DD01) NONVSAM PURGE IKJ56228I DATA SET FILE NOT IN CATALOG OR CATALOG CAN NOT BE ACCESSED IDC0548I ** MEMBER DD01 NOT DELETED IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 8 IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 8 === Now , a colleague asked me to delete with IEBFR14 : //DELETE EXEC PGM=IEFBR14 //Duc DD DSN=SYS12048.T104505.RA000.IBMUSER.R0100008, // DISP=(OLD,DELETE),SPACE=(TRK,(0,0)),VOL=SER=WORK01,UNIT=3390 This worked !!! But when i asked him to explain me how does this worked and not IDCAMS , he could not give me the reason. Can you please tell me ? <SNIPPAGE> IDCAMS is telling you that there was no CATALOG entry for this data set. If you check the messages from IDCAMS (IDCnnnn) you will see what was occurring. IDCAMS, as I recall, uses DYNALLOC which is why you see the message IKJ56228I (you should look this one up too). Now IEFBR14 didn't do a thing. Nothing, zip, zilch, nada, etc. What did happen is, "system" allocation got invoked at step start, and an attempt was made to allocate the data set to this job for this step using the VOL=SER= info you gave for the type device (UNIT=3390). So ALLOC read the VTOC for this volume, and apparently found the data set, and since the normal disposition was DELETE, then when the step ended (which should have been instantaneously, since IEFBR14 just sets R15=0 and BR14 (branches) right back to the caller (probably in this case to the SVC 3 in the PRB). So the system promptly deleted the data set from that specific volume (you should see this in the JESYSMSG DD for the JOB in SDSF). Since there was no catalog entry, everything is good. Now, go whack the person that wrote the JCL that has the following similarly coded DD statement: //SYSUT3 DD UNIT=3390,SPACE=(CYL,10),DISP=(NEW, CATLG) This is what produces a data set name like this: SYS12048.T104505.RA000.IBMUSER.R0100008 The DISP is NOT needed for a "step only" work file / data set. So during DEALLOCATION at step end, this type of data set just goes away. Regards, Steve Thompson opinions expressed by this poster may not reflect those held by poster's employer. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
