Johnny, I might be wrong but I interpret the manual to say that you can only rename the HLQ and it says it has to be a linear vsam file. I was under the impression that I could not rename a ksds vsam file but I could be wrong. Wayne
-----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Johnny Luo Sent: Tuesday, January 29, 2008 2:43 AM To: [email protected] Subject: DSS COPY/RENAME failed (ADR971E) Hi, We have a production job to COPY/RENAME an extended KSDS and it runs normally for some days before giving us a RC=8: DR006I (001)-STEND(01), 2008.028 01:38:23 EXECUTION BEGINS ADR411W (001)-DDFLT(02), DATA SET PROD.OLD IN CATALOG CATALOG.UCAT ON VOLUME BP9E97 WAS NOT SERIALIZED ON REQUEST ADR971E (001)-AMOVE(01), LOGICAL COPY FOR CLUSTER PROD.OLD IN IN CATALOG CATALOG.UCAT FAILED, 4 ADR439E (001)-PREVS(15), A PREALLOCATED DATA SET WITH NEW NAME NEW NAME PROD.NEW WAS FOUND FOR DATA SET PROD.OLD BUT WAS UNUSABLE, 68 Here are the DSS statements we're using: COPY DATASET(INCLUDE(PROD.OLD)) - RENAMEU((PROD.OLD,PROD.NEW)) - OPTIMIZE(4) TOL(ENQF) STORCLAS(SCCPCRD) REPLACEU Explanation for ADR971E is: (RC=4) A logical COPY was requested for an extended format VSAM data set and DFSMSdss could not enqueue on the data set name. DFSMSdss requires IDCAMS to copy the data set. A logical COPY using IDCAMS cannot be performed on an extended format VSAM data set that is open for update. The TOLERATE keyword is not supported. However, we don't have other users openning it in I-O mode while doing the copy/rename. *More strangely, if we remove the del/define step (we define the target KSDS before the copy/rename), the job executed successfully, at least for the past two days!!!* I have done the various tests and feel a little lost. Actually I was not able to trigger another ADR971E messages in my tests. The last information I can supply is about the space allocation. If we del/define the target KSDS, we can see the messages concerning space constraint relief: IGD17287I DATA SET PROD.NEW COULD NOT BE ALLOCATED NORMALLY, SPACE CONSTRAINT RELIEF (MULTIPLE VOLUMES) WILL BE ATTEMPTED IGD17286I SPACE CONSTRAINT RELIEF WAS USED TO ALLOCATE DATA SET PROD.NEW, DATA WAS SPREAD OVER MULTIPLE VOLUMES IGD17070I DATA SET PROD.NEW ALLOCATED SUCCESSFULLY WITH 1 STRIPE(S). IGD17172I DATA SET PROD.NEW IDCAMS SYSTEM SERVICES IS ELIGIBLE FOR EXTENDED ADDRESSABILITY After removing the del/def step, there are no such messages in DSS job log. It seems that we allocate too much spaces in the DEFINE step and if letting DSS do it automatically (remove the del/define step) , it's so smart to calculate the right size to use. But is it relevant? Having struggled with it for 12 hours, I need some hints from experts here -_- Thanks. Johnny ---------------------------------------------------------------------- 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
