Thanks to all who've offered their thoughts.
To Peter Relson, let me apologize if I've added to your frustration level
in any way, shape or form. This is/was not my intent, I'm just trying to
understand why a new and improved DSORG prohibits actions allowed with an
older DSORG. I'm hoping your frustration might be reduced with the
knowledge that any LNKLST UNALLOCATEs (PDSE or PDS) are done in an LPAR
used only by the SYSPROG performing the task. Please also understand the
frustration of a customer who (long after working hours) can't delete a
dataset which has no displayable enqueues once removed from XCFAS/LLA and
needs IBM help to be routed to APAR info documenting a PDSE 'permanent
restriction'. Thanks for the info that z/OS 1.8 may change things.
Some have offered the possibility of building and activating a new
LNKLST without the problem PDSE and Peter mentioned using SETPROG LNKLST
UPDATE JOB(*) with its associated risk. I built a test scenario. Unless
I missed something during the test, the 'global connect' (by DFSMS?) still
prohibits the delete.
A summary of the test, not mentioning relief of enqueues needed:
1. Cloned a 'bad' LNKLST'd PDSE, named as *.NEW.
2. Defined a new LNKLST called LNKLST1, copied from current.
3. Added *.NEW PDSE to LNKLST1
4. Deleted old 'bad' PDSE from LNKLST1
5. Activated LNKLST1 (probably not needed due to next step)
6. SETPROG LNKLST UPDATE JOB(*)
7. Did a D PROG,LNKLST,JOBNAME=*
All tasks (*MASTER* included) now are using LNKLST1.
No tasks are using LNKLST00, the IPL time LNKLST.
8. Tried to delete the 'bad' PDSE and received:
IEC614I SCRATCH FAILED - RC 008, DIAGNOSTIC INFORMATION IS (043D57D3)
9. Testing further, was able to rename 'bad' PDSE as *.TEST.
10. Tried to delete *.TEST and still received:
IEC614I SCRATCH FAILED - RC 008, DIAGNOSTIC INFORMATION IS (043D57D3)
Still don't see a way to delete the original 'bad' PDSE short of IPLing
without it in LNKLST.
I need to put this issue aside as a DR exercise (not a test in this shop,
but true prod switchover...there's no test like production) is upcoming
this weekend. Responses may not occur for a while.
Paul
----------------------------------------------------------------------
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
