Portal | Manuals | References | Downloads | Info | Programs | JCLs | Mainframe wiki | Quick Ref
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Profile Log in to check your private messages Log in
 
Cannot change DATACLAS on DFSMSdss restore

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM
View previous topic :: :: View next topic  
Author Message
Alan Playford

New User


Joined: 22 Aug 2012
Posts: 30
Location: UK

PostPosted: Tue May 01, 2018 6:43 pm    Post subject: Cannot change DATACLAS on DFSMSdss restore
Reply with quote

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?
Back to top
View user's profile Send private message

Alan Playford

New User


Joined: 22 Aug 2012
Posts: 30
Location: UK

PostPosted: Tue May 01, 2018 7:22 pm    Post subject:
Reply with quote

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?!
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8391
Location: Dubuque, Iowa, USA

PostPosted: Tue May 01, 2018 7:22 pm    Post subject: Reply to: Cannot change DATACLAS on DFSMSdss restore
Reply with quote

Quote:
It gets changed (with messages to verify) if you do a straight ALLOCATE of the dataset, or if you test it in ISMF.
Why not ALLOCATE the dataset and use REPLACEU on the RESTORE?
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8391
Location: Dubuque, Iowa, USA

PostPosted: Tue May 01, 2018 7:29 pm    Post subject:
Reply with quote

Quote:
That, surely, is a major flaw in the SMS undertaking?!
Since yours is the first post I've ever seen on this particular topic, I wouldn't consider it much of a "major flaw"!
Back to top
View user's profile Send private message
enrico-sorichetti

Senior Member


Joined: 14 Mar 2007
Posts: 10515
Location: italy

PostPosted: Tue May 01, 2018 7:29 pm    Post subject: Reply to: Cannot change DATACLAS on DFSMSdss restore
Reply with quote

Quote:
That's extremely worrying?
....
That, surely, is a major flaw in the SMS undertaking?!


nope ... it is a flaw in Your thinking icon_cool.gif

the data class concerns roughly the constructs used for allocation

what if the data class You choose conflicts with the characteristics of the dataset being restored ?
Back to top
View user's profile Send private message
Alan Playford

New User


Joined: 22 Aug 2012
Posts: 30
Location: UK

PostPosted: Tue May 01, 2018 7:41 pm    Post subject:
Reply with quote

@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?!
Back to top
View user's profile Send private message
enrico-sorichetti

Senior Member


Joined: 14 Mar 2007
Posts: 10515
Location: italy

PostPosted: Tue May 01, 2018 7:47 pm    Post subject: Reply to: Cannot change DATACLAS on DFSMSdss restore
Reply with quote

NOPE icon_smile.gif
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 )
Back to top
View user's profile Send private message
Alan Playford

New User


Joined: 22 Aug 2012
Posts: 30
Location: UK

PostPosted: Wed May 02, 2018 1:55 am    Post subject:
Reply with quote

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!
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8391
Location: Dubuque, Iowa, USA

PostPosted: Wed May 02, 2018 2:05 am    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8714
Location: Welsh Wales

PostPosted: Wed May 02, 2018 11:26 am    Post subject:
Reply with quote

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 icon_eek.gif
Back to top
View user's profile Send private message
Willy Jensen

Active User


Joined: 01 Sep 2015
Posts: 219
Location: Denmark

PostPosted: Wed May 02, 2018 1:29 pm    Post subject:
Reply with quote

maye give it another try adding the NULLSTORCLAS option? I seem to recall that helped me in the past.
Back to top
View user's profile Send private message
Pete Wilson

Active User


Joined: 31 Dec 2009
Posts: 463
Location: London

PostPosted: Sat Jun 09, 2018 9:06 pm    Post subject:
Reply with quote

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.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts How to add new LPARs and change exist... Alan Playford All Other Mainframe Topics 0 Thu Aug 23, 2018 5:52 pm
No new posts row change timestamp charanmsrit DB2 3 Tue Jul 10, 2018 12:30 pm
No new posts Repeat Sequence Number Until change i... rahulabvp DFSORT/ICETOOL 6 Thu Mar 29, 2018 12:51 pm
No new posts Old gds of GDG not rolledoff after AD... Wallace Lee IBM Tools 3 Fri Feb 09, 2018 9:34 pm
No new posts How to change the logon screen info o... sakthikumarT TSO/ISPF 5 Fri Dec 29, 2017 6:44 pm

Facebook
Back to Top
 
Job Vacancies | Forum Rules | Bookmarks | Subscriptions | FAQ | Polls | Contact Us