Using DFDSS to restore some Customer datatsets where we don't want to change their dataset names.
(Normally, we'd setup a new HLQ and assocuated USERCAT if necessary, then rename on the RESTORE)
(Also note we'd like to add an extra qualifier on the restored datasets, excpet DFDSS STILL doesn't allow that? FDR DSF allows it, but cannot read DFDSS dumps! Grr!)
Anyway, non-VSAM files (sequential, PDS, PDSE) files work fine.
Using RECATLOG(newusercat) where "newusercat" is a user catalog connected to the mastercatalog via IMPORT CONNECT, but which doesn't have any ALIAS defined to it yet.
VSAM file restore gets messages:
ADR396I (001)-NEWDS(01), DATA SET D.HDI.TEST.VSAM ALLOCATED, IN CATALOG CATALOG.CUSTOMER.HDI.RENAMED.HDSNS, ON VOLUME(S): WWRK01 (001)-TDUNL(01), CATALOG CATALOG.CUSTOMER.HDI.RENAMED.HDSNS IS NOT IN STEPCAT/JOBCAT/MASTERCAT STRUCTURE. DATA SET
D.HDI.TEST.VSAM WILL NOT BE PROCESSED
Kinda interesting, as we are on zOS v2.3 and JOBCAT/STEPCAT hasn't been available for some time now?
And we DON'T want to put these things in the mastercatalog!
The message doesn't help too much, bleating on about "DSS is not able to pass a target catalog that might be out of the standard order of search."
Well, just what is that?
Especially when I've specifically told DFDSS which usercatalog to use?
Anybody else had this problem, knows what the real underlying problem is, and hopefully knows a way around it?
(By the way, this is not dumping from a 3390-9 and restoring to an EAV volume, as it appears CI/CA changes may occur when doing that! This is purely 3390-9 to 3390-9.)
You might want to use CATALOG rather than RECATALOG. According to the manual:
When you restore a data set, you might need to catalog it in the standard
order of search or recatalog it in its original catalog. The CATALOG
keyword catalogs the data set in the standard order of search. The
RECATALOG(*) keyword catalogs it in the same catalog that points to the
source data set.
It looks like originally a dataset called D.HDI.TEST.VSAM was cataloged in CATALOG.CUSTOMER.HDI.RENAMED.HDSNS on the source system where it was dumped, and DSS is trying to restore and recatalog to that same catalog. If you create a usercatalog alias 'D' pointing to some existing catalog and just specify CATALOG that should work. Otherwise define the CATALOG.CUSTOMER.HDI.RENAMED.HDSNS with alias for 'D' and use RECATALOG.
Or, use RENAMEU(oldname,newname) to rename it to a name with an existing usercatalog alias.
DSS can do generic rename to a point, as long as you're not changing the number of qualifiers in the dsname, in which case you have to have specific old/new names. I've always found this DSS generic rename a real pain in the arse to use though.
This is the relevant section of the manual for RENAME/RENAMEU and the oldname newname filtering. All very convoluted
The syntax for the old name filter is exactly like that of the INCLUDE
filter, and their rules match.
Examples of valid syntax for the new name filter are:
** Restore the data set with the old name. This provides a powerful
tool whereby some data sets can be restored with the old name
and others can be restored with the new name.
* If DSNAME has one level, then restore with old name.
A.** First level of DSNAME replaced by A.
A.B.** First two levels of DSNAME replaced by "A.B".
*.A.** Second level of DSNAME replaced by A.
**.BCD Last level of DSNAME replaced by BCD.
DATE.**.LIST First and last levels are replaced by DATE and LIST.
Q.* If DSNAME has two levels, replace the first by Q.
Q.*.B If DSNAME has three levels, replace the first and last by Q and
*.*.SYSLIST If DSNAME has three levels, replace the last by SYSLIST.
ABC.DEF No asterisk in substring; replace the entire name with
Examples of invalid syntax for the new name filter are:
**.DATA.** Invalid (level to be replaced is ambiguous).
*SYS* Invalid (a qualifier is not completely replaced).
SYS* Invalid (a qualifier is not completely replaced).
*SYS Invalid (a qualifier is not completely replaced).
SYS*TEM Invalid (a qualifier is not completely replaced).
SYS.DAT% Invalid (a qualifier is not completely replaced).
Restriction: The use of the wildcard character (%) is not
supported for the new name filter of the RENAME, RENAMEU, or
RENUNC keywords for the COPY or RESTORE operations.
You cannot change the number of qualifiers unless you use fully-qualified
names, for example, RENUNC((A.B.C,A.B.C.D)).
If the new name filter has errors, the data set is not restored. The new
name that is derived is truncated to fit 44 characters. If it ends with a
period, that period is also truncated.
If the new name is not fully qualified, then it must contain the same
number of qualifiers as the old name. For example, given the old name
filter DATE.** and the new name filter DATE.*.*.LIST,
DATE.MARCH.TODAY.OLDLIST would be renamed, but DATE.MARCH.OLDLIST would
not. <==== this just seems wrong to me!!
If two or more rules match the old data set name, the resulting new name
is the first match.
GDG relative generation filtering cannot be used for old or new names.
Thanks for the reply Pete.
The problem (at that time) was that we were trying to build up the catalog entries for Customer datasets being restored with names which we didn't particular want or use?
The HLQ could have caused conflicts with any of our own datasets, and so we were just trying to restore to a volume and populate a separate user catalog with the names in readiness for perhaps a new LPAR to use this in its entirety and separate from any other LPAR.
Hence we didn't have any ALIAS entries pointing from our system into the Customer user catalog.
I still say that DFDSS tends to treat these VSAM entries differently to non-VSAM ones, but we've moved past that problem now.