PAGE 0001 5695-DF175 DFSMSDSS V1R11.0 DATA SET SERVICES 2011.132 08:38
COPY DATASET(INCLUDE(HLQ.SOME.GDG)) -
REPLACEUNCONDITIONAL (HLQ1.SOME.GDG) -
CATALOG TGTGDS(ACTIVE) -
ALLDATA(*) ALLEXCP
ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'COPY '
ADR109I (R/I)-RI01 (01), 2011.132 08:38:56 INITIAL SCAN OF USER CONTROL STATEMEN
ADR124E (001)-RI01 (02), DELIMITER '(' IS NOT PROPERLY PRECEDED BY A CONSTANT OR
ADR131E (001)-RI03 (01), ABOVE TEXT BYPASSED UNTIL NEXT COMMAND
ADR017E (001)-CLTSK(01), 2011.132 08:38:56 TASK NOT SCHEDULED DUE TO ERROR. TASK
ADR012I (SCH)-DSSU (01), 2011.132 08:38:56 DFSMSDSS PROCESSING COMPLETE. HIGHEST
SYNTAX
TASK 001
ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'COPY '
ADR109I (R/I)-RI01 (01), 2011.132 08:03:14 INITIAL SCAN OF USER CONTROL STATEMEN
ADR141E (001)-RI03 (03), ERROR IN DATA SET NAME BCST.FIRST.GDG
ADR017E (001)-CLTSK(01), 2011.132 08:03:14 TASK NOT SCHEDULED DUE TO ERROR. TASK
ADR012I (SCH)-DSSU (01), 2011.132 08:03:14 DFSMSDSS PROCESSING COMPLETE. HIGHEST
SYNTAX
TASK 001
Looked in to the manuals for ADRDSSU, but was not exactly sure - what to look for...
Joined: 03 Oct 2009 Posts: 1787 Location: Bloomington, IL
A GDG base entry has so little information in it that it's difficult to imagine what you are trying to accomplish. In copying one base to another, what information do you expect to be copied?
Nothing. They are creating a new LPAR for this they need to copy some GDGs from existing LPAR to another.
For now, I used an IDCAMS job with around 100 steps, each defining a new GDG - but the short coming is, you have to run the LISTCAT for the existign GDGs to see teh attibutes for new GDGs. I know there is more work of this nature coming my way, so was thinking if I can eliminate manual stuff of checking the the attibutes.
Joined: 03 Oct 2009 Posts: 1787 Location: Bloomington, IL
So, do you have (and are authorized to use) Rexx in the source environment? Do you have Open Software's REXXTOOLS package? Are the source and target LPARs JES2 or JES3?
So, do you have (and are authorized to use) Rexx in the source environment? Do you have Open Software's REXXTOOLS package?
REXX I can use, in the source environment though, have not tried the open source REXX ever at this shop.
Quote:
Are the source and target LPARs JES2 or JES3?
They are JES2.
Well, I'm an End-user, an appliction Developer - so do not have too much rights to choose the tools. And, at times, I wonder -- are the ones in charge, really have the mindset they need for such tasks! Well, to start with - when I asked my lead - do you want me to create the Model DSCB as well for these newly created GDGs, though I know - the new LPAR is going to be SMS managed, however, I know they are going to use , possibly, some non-SMSed managed volumes as well..so tell me please.
She: DCB is not needed.
Me: I said, DSCB Model for GDG not DCB.
She: A long pose...
GDG base is not a datset as such it is just a catalog entry and as such cannot be copied. There is a good chance that lying around your system somewhere there is an IBM supplied program called MCNVTCAT this can take the output from a LISTC command and rebuild the DEFINE statements . In the past sysprogs used this program to rebuild a Master Catalog. The program will create
members in a PDS one of which will be called GDG, this will contain all the statements you require. Be aware that if this program runs on a a version of z/OS later than 1.7 the output should be carefully checked as LISTC changed with 1.8
GDG base is not a datset as such it is just a catalog entry and as such cannot be copied. There is a good chance that lying around your system somewhere there is an IBM supplied program called MCNVTCAT this can take the output from a LISTC command and rebuild the DEFINE statements . In the past sysprogs used this program to rebuild a Master Catalog. The program will create
members in a PDS one of which will be called GDG, this will contain all the statements you require. Be aware that if this program runs on a a version of z/OS later than 1.7 the output should be carefully checked as LISTC changed with 1.8
Thanks nevilh.
Thanks for coining out the word "MCNVTCAT", I had been reading about this since the day you put your message here. However, not having much time on my hands to do lot of reading but I won't leave it. Looks like, it'll give me what I'm looking for.
Click HERE and look at some code that will get the attributes of any given GDG bases.
You can then tailor the output to produce the GDG define statements to be processed on the other LPAR.
Thanks expat. I'm not good with REXX but has kept your code for reference. To do the same thing, actually, used a combination of LISTCAT and Sort, shown below: