Cannot change DATACLAS on DFSMSdss restore

Alan Playford · New User Joined: 22 Aug 2012 Posts: 48 Location: UK

Guys,
We have a DFSMSdss dumped dataset transferred from a Customer.
This contains several datasets, but one is giving problems on RESTORE.

DFSMSdss job and parameters:
//STEP0100 EXEC PGM=ADRDSSU
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//DFDSS DD DISP=OLD,DSN=dfsmsdss.dumped.dataset
//SYSIN DD *
RESTORE INDDNAME(DFDSS)
DATASET(INCLUDE(**.oldllq))
RENUNC (newhlq)
NULLMGMTCLAS
IMPORT
CATALOG

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?

Alan Playford · New User Joined: 22 Aug 2012 Posts: 48 Location: UK

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 Sample · Posted: Tue May 01, 2018 7:22 pm

Robert Sample · Posted: Tue May 01, 2018 7:29 pm

enrico-sorichetti · Posted: Tue May 01, 2018 7:29 pm

Alan Playford · New User Joined: 22 Aug 2012 Posts: 48 Location: UK

@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?!

enrico-sorichetti · Posted: Tue May 01, 2018 7:47 pm

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 )

Alan Playford · New User Joined: 22 Aug 2012 Posts: 48 Location: UK

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!

Robert Sample · Posted: Wed May 02, 2018 2:05 am

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.

expat · Posted: Wed May 02, 2018 11:26 am

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.

Like Robert above, I may be wrong

Willy Jensen · Posted: Wed May 02, 2018 1:29 pm

maye give it another try adding the NULLSTORCLAS option? I seem to recall that helped me in the past.

Pete Wilson · Posted: Sat Jun 09, 2018 9:06 pm

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.

Painful business I know.