I just went through a similar situation. If I remember what I read,
DF/dss actually invokes IDCAMS "under the covers" to actually perform
the action you are trying. IF you dump the zfs dataset, and restore it
with a newname, it should work properly.
Doug
On 16-Nov-10 09:28, R.S. wrote:
The following scenario:
z/OS 1.11
DSS job
COPY DS(INC(**) EXC(SYS1.VVDS.**)) -
LOGINDDNAME(IND) -
CANCELERROR TOLERATE(ENQF) -
OUTDD(OTD) ALLDATA(*) ALLEXCP -
RECATALOG(CAT.MAST.NEWCAT) -
RENAMEU(ZFS.OLDSYS.**,ZFS.NEWSYS.**)
The job succesfully copies all ZFS (VSAM LDS) datasets, *except* the
following one: ZFS.OLDSYS.SHPUROOT
DSS end with RC=8 and te following message.
ADR485E (001)-AMOVE(01), CATALOG CAT.MAST.NEWCAT IS NOT IN
STEPCAT/JOBCAT/MASTERCAT STRUCTURE. DATA SET ZFS.OLDSYS.SHPUROOT WILL
BE PROCESSED.
Manual says: he NONSMS cluster named in the message required DFSMSdss
to use IDCAMS or VSAM I/O to perform the COPY or RESTORE. This
requires that both the source and target cluster (allocated by
DFSMSdss) be accessible via the catalog structure.
I have no idea why this dataset requires IDCAMS, while other datasets
were succesfully processed.
Any clue???
BTW: I googled for ADR485E - first hit says about empty cluster - this
cluster is NOT empty.
----------------------------------------------------------------------
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
