Have you tried to do this recently. IDCAMS delete does an HDELETE on a ML2 migrated file under zOS 1.9 without doing the recall.
Regards Otto Schumacher Technical Support, CICS EDS, an HP Company Ahold Account 2000 Wade Hampton Blvd. LC1-302 Greenville, South Carolina, 29615 Tel: 864 987-1417 Fax: 864 987-4500 E-mail: [email protected] We deliver on our commitments so you can deliver on yours. -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Don Williams Sent: Wednesday, March 25, 2009 5:52 PM To: [email protected] Subject: Re: UNABLE TO DELETE ML2 DSN I've had a similar problem with trying to TSO DEL a migrated data set. While I'm not offering you a solution, I did submit a design change request as indicated in my IBM PMR: ========================================================== Abstract: TSO DEL 'dataset' NOSCRATCH fails >From the ISPF option 6 command line I entered the following command: del 'SYSIOF.OPERLOG.IOFINDEX' noscratch ARC1001I SYSIOF.OPERLOG.IOFINDEX RECALL FAILED, RC=0002, REAS=0004 ARC1102I DATA SET IS NOT MIGRATED/BACKED UP ARC1020I DFSMSHSM IS RECALLING FROM TAPE DSN=SYSIOF.OPERLOG.IOFINDEX, PLEASE RETRY THE USER REQUEST AFTER THE RECALL HAS COMPLETED. IDC3014I CATALOG ERROR+ IDC0551I ** ENTRY SYSIOF.OPERLOG.IOFINDEX NOT DELETED IDC0014I LASTCC=8 IDC3007I ** VSAM CATALOG RETURN CODE IS 38 I've reported this problem as far back as OS/390 2.10. I still strongly feel that from TSO, I should be able to delete noscratch any entry that I could also delete using the same command in batch execution of IDCAMS. Thanks, Don Williams <<snip>> Greetings, Only when a user is logged on under group ARCCATGP does DFSMShsm bypass the automatic recall for UNCATALOG, RECATALOG, and DELETE NOSCRATCH requests for migrated data sets. . If you want certain authorized users to be able to perform these operations on migrated data sets without recalling the data sets, you need to perform the following steps: . 1. Define a RACF catalog maintenance group named ARCCATGP. For example: ADDGROUP (ARCCATGP). . 2. Connect the desired users to that group. CONNECT (userid1,. . .,useridn ) GROUP(ARCCATGP) AUTHORITY(USE) http://publibfi.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/dgt2i450/1.9.6?DN= SC35-0418- 05&DT=20060629040441&SHELF=dgt2bk61&CASE=&PATH=/bookmgr/ The situation that is described and tested/recreated, is a known documented limitation/scenario. However, I do understand your concerns, and having both TSO and batch run the same way (even though they are different processes) does appear to be a good point. This item is not a defect, but we can still address it. Do you wish to open a Design Change Request/Suggestion? I can open, populate, and monitor it for you if you wish. Please let me know how you'd like to proceed. Thanks, Albert Szeto, IBM DFSMShsm Level 2 Action taken: update Action plan: await feedback, set follow up for March 26 -IM00772 -5695DF170 - 09/03/20-12:38- RESPOND ELECTRONICALLY: Hi Albert, Yes, I would like to submit a MR or DCR. Our "special" users don't want to be permanently connected to ARCCATGP. As I wrote earlier in the PMR to Laurie: ------------------------------------------------------------------------ - It seems to be a bit much to require a user to: 1. logoff, 2. logon with a special connect group, 3. delete the desired data set(s), 4. logoff again, 5. logon back with their normal connect group to resume their work. It wastes my time. No special connect group is needed in batch. It is aggravating when the same command (I know technically they are not the same) works in batch, but not TSO (or vice versa). I did not like the difference 10 to 15 years ago, and I still don't like it. ------------------------------------------------------------------------ - Thanks, Don Williams "The time is always right to do what is right" -- Martin Luther King, Jr. =SZETO, ALBERT -5695DF170 - 09/03/20-18:50- =SZETO, ALBERT -5695DF170 - 09/03/20-20:26- Greetings, I have opened MR0320096938 for your design change/suggestion. Thanks, Albert Szeto, IBM DFSMShsm Level 2 ========================================================== Hopefully IBM will decide to enhance TSO/HSM to handle the situation (some time in the next decade?). Don Williams ---------------------------------------------------------------------- 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
