There was an APAR written (way way back when (check IBMLink).
The gist of the apar was, if the only action was to delete the file, do
not have DFHSM recall the dataset.
To the best of my recollection, this was a DFSMS apar. It never made it
to TSO.
Thus, IDCAMS (batch) DEL dsn NOSCRATCH will delete the file. TSO DEL dsn
NOSCRATCH will attempt to recall the file.
HTH,
***
<<SNIP>>
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
==========================================================
</snip>
<</snip>>
----------------------------------------------------------------------
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
