Restore says:
ADR780I (001)-TDDS (01), THE INPUT DUMP DATA SET BEING PROCESSED IS IN LOGICAL DATA SET FORMAT AND WAS CREATED BY Z/OS DFSMSDSS
VERSION 2 RELEASE 1 MODIFICATION LEVEL 0 ON 2018.088 17:22:07
ADR711I (001)-NEWDS(01), DATA SET dumped.dataset.llq HAS BEEN ALLOCATED WITH NEWNAME
newhlq.dataset.llq USING STORCLAS EXTENDED, DATACLAS PSEXTCZ, AND NO MGMTCLAS
ADR474I (001)-TDNVS(01), DATA SET newhlq.dataset.llq CONSISTS OF 00060870 TARGET TRACKS AND 00060105 SOURCE TRACKS
ADR908E (001)-SDMXI(01), RESTORE OF EXTENDED SEQUENTIAL DATA SET newhlq.dataset.llq FAILED
ADR910E (001)-SDMXI(01), AN ERROR WAS ENCOUNTERED DURING DATA MOVEMENT PROCESSING. RETURN CODE = 500005E3, REASON CODE = 00040010
ADR415W (001)-TDLOG(01), NO DATA SETS WERE COPIED, DUMPED, OR RESTORED FROM ANY VOLUME
ADR480W (001)-TDLOG(01), THE FOLLOWING DATA SETS WERE NOT PROCESSED FROM THE LOGICALLY FORMATTED DUMP TAPE DUE TO ERRORS:
oldhlq.dataset.llq
Now, the NULLMGMTCLAS has worked, and the ACS routines have been checked especially for DATACLAS. In this case, it's an extended format dataset that was dumped, and so the DC should be EXTENDED, SC should be extended, and that results in SG of some SMS volumes accordingly (EXT datasets HAVE to be SMS-managed).
However, as you can see, the DC hasn't been changed here?
It gets changed (with messages to verify) if you do a straight ALLOCATE of the dataset, or if you test it in ISMF.
So how do I get this external site's DC of PSEXTCZ to be modified on a DFSMSdss restore?
You can't override it, but because its extended format, it must go to an SMS volume, so at least needs the SC setting up (that's OK, by the way).
Anybody else in the habit of restoring externally-dumped datasets with SMS characteristics?
If so, how do you change the Dataclas upon DFSMSdss restore?
Found this in the zOS v2.3 z/OS DFSMSdss Storage
Administration manual p93 under Chapter 6. Managing availability with DFSMSdss .....
"Note that the RESTORE command does not invoke the data class ACS routine, so no data class is assigned. (The dataset attributes are already defined, therefore the DATACLAS routine is not called because it's not relevant in this process.)
To cause the data class ACS routine to be invoked, create a new dataset either with the IDCAMS DEFINE command or a JCL DD statement with DISP=(NEW,CATLG)"
That's extremely worrying?
it means you either have to know the dataset attributes so you can pre-define it and then RESTORE with REPLACE, or else it has to be (somehow?) dumped without that DATACLAS attribute?
That, surely, is a major flaw in the SMS undertaking?!
@Robert - The trouble is that these are externally generated dumps from Customers, and so we'd need to know the attributes before allocating? (something we don't have to do right now, as DFSMSdss takes care of it).
Well, perhaps not a major flaw, but it quite stunned me when I found this out?
@Enrico - Not so sure that my thinking is flawed, but rather that there's an inconsistency here that I certainly wasn't aware of?
You can override restored datasets with MGMTCLAS and STORCLAS, biut not DATACLAS? And both of those (especially MGMTCLAS) might also conflict with the original? (not so much STORCLAS of course).
Besides, the ACS routines normally allow, deny, override attributes as coded, but it seems in this case that DATACLAS routines aren't even looked at?
I just find that a bit strange?!
NOPE
the data class deals with the attributes of the dataset
the management class deals with how You want to handle the dataset ( backups, expiration, ... )
IIRC You can change thru the ISMF dialogs the management class of a dataset ( no conflict whatsoever will arise )
Enrico, you're right, and I can understand the logic of your argument.
However, I still have the problem that
(a) The DATACLAS the dataset was dumped with doesn't exist on this system
(b) I don't want to have to add them each time because with many Customers ... well ...... you can guess
So, do you have any suggestions on how to get around this?
Or doesn't the DATACLAS of a dataset matter that much (as long as I can get it allocated in the first place?)
I know that DATACLAS isn't shown on the ISPF 3.4 screens etc, so maybe not?
To be honest, I suspect that there was some sort of problem when the dataset was dumped, giving the error line:
ADR910E (001)-SDMXI(01), AN ERROR WAS ENCOUNTERED DURING DATA MOVEMENT PROCESSING. RETURN CODE = 500005E3, REASON CODE = 00040010
But I haven't been able to find any further information on this yet?
Any (clean!) suggestions would be welcomed!
P.S. We've asked for a separate re-dump of that dataset for a subsequent RESTORE attempt, so this thread might be updated to say "actually, no problem!" ? I really hope that's the case!
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
IIRC, we used to use BYPASSACS and ADMIN to force the system to not use the source dataclass -- but it's been a while so I may not remember that correctly.
Joined: 14 Mar 2007 Posts: 8797 Location: Welsh Wales
If I remember correctly from my days as a DASD farmer, DATACLAS is the only SMS parameter that I couldn't change when doing a restore / recall / DFdss move.
You CANNOT change the Dataclas of a dataset during a DFDSS RESTORE as it defines the actual attributes of the dataset! This can be anything from things such as Extended Format, Extended Addressability or Compression to name a few, so naturally these cannot be changed or the dataset would be unusable.
It makes no difference if you predefine the dataset on your own system with a different Dataclas and try and overwrite it with REPLACEU because DFDSS will delete it first before restoring due to differences in the attributes.
The only options are:
- get the customers to provide their Dataclas names and attributes and define them to your SMS configuration
- ask the customer to create the datasets without a Dataclas on their system so there's no Dataclas passed on the DFDSS RESTORE.
- ask the customer to supply the backup in a different format such as a SORT or REPRO output backup that you can read in and output to a new dataset on your system where it will have a new Dataclas assigned automatically, or you specify a new one on the JCL creating the new dataset.
