|
|
| Author |
Message |
quanzhong
New User
Joined: 12 Aug 2008
Posts: 37
Location: china
|
|
|
|
Hi,
now i am meeting a problem..
in my job can be seen as follows in short.
| Code: |
step1 //*create a GDG generation refered by program.
//ABSO DD DSN=&HLQ..CMS.ABSO.S&BSEG..BKP(+1),
// DISP=(NEW,CATLG,DELETE),
// UNIT=&DISK,SPACE=(CYL,(10,10)),
// DCB=(&GDGMOD,RECFM=VB,LRECL=2307)
//*
......
step5
......
step9 //*use that generation
//ABSI DD DSN=&HLQ..CMS.ABSO.S&BSEG..BKP(+1),DISP=OLD
......
|
unfortunately, my job failed at step5, after getting through all mistakes,
i restarted that job, but job failed again at step9...with collegue's suggestion, I override that statement.
| Code: |
//ABSI DD DSN=&HLQ..CMS.ABSO.S&BSEG..BKP(+0),DISP=OLD
|
and i got what wanted... though the problem had resolved, but i want to know why, and how to avoid that kind of mistake.
as the job spool has been cleared, so I couldn't provide the error message.. Hope that you all can get my problem.. |
|
| Back to top |
|
 |
References
|
|
 |
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 3544
Location: Brussels once more ...
|
|
|
|
| The relative generation is +1 for the whole job. Once the job ends or abends the +1 then becomes 0 for any restart / reun of the job. |
|
| Back to top |
|
|
hchinnam
Active User
Joined: 18 Oct 2006
Posts: 68
|
|
|
|
| quanzhong wrote: |
unfortunately, my job failed at step5, after getting through all mistakes,
i restarted that job,
|
I guess you would have restarted the JOB after STEP1. So the GDG numbers are updated with the version created in previous run (Run that has failed). When you restart the JOB there is no +1 version (as it has already been made version 0). So it has failed. |
|
| Back to top |
|
|
quanzhong
New User
Joined: 12 Aug 2008
Posts: 37
Location: china
|
|
|
|
Hi,
can you provide a link on GDG? thanks..
It seems that related material is very limited. |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 3544
Location: Brussels once more ...
|
|
|
|
hchinnam
| Quote: |
| I guess you would have restarted the JOB after STEP1. So the GDG numbers are updated with the version created in previous run (Run that has failed). When you restart the JOB there is no +1 version (as it has already been made version 0). So it has failed. |
The correct terminology is GENERATION not version.
These two terms are perfectly valid in reference to GDS but with completely different meanings. Please use the correct terms when addressing a question, because if you do not know what you are talking about how can anyone else be expected to. |
|
| Back to top |
|
|
superk
Moderator Team Head
Joined: 26 Apr 2004
Posts: 3304
Location: Charlotte,NC USA
|
|
| Back to top |
|
|
hchinnam
Active User
Joined: 18 Oct 2006
Posts: 68
|
|
|
|
expat,
point noted.
However one quick question. Do you know when VERSION number of a GDG generation changes. I never seen one with a value other then zero. |
|
| Back to top |
|
|
superk
Moderator Team Head
Joined: 26 Apr 2004
Posts: 3304
Location: Charlotte,NC USA
|
|
|
|
| hchinnam wrote: |
| However one quick question. Do you know when VERSION number of a GDG generation changes. I never seen one with a value other then zero. |
From the above links:
| Quote: |
The number of generations and versions is limited by the number of digits in the absolute generation name; that is, there can be 9,999 generations. Each generation can have 100 versions.
The system automatically maintains the generation number. The number of generations kept depends on the size of the generation index. For example, if the size of the generation index permits ten entries, the ten latest generations can be maintained in the GDG.
The version number lets you perform normal data set operations without disrupting the management of the GDG. For example, if you want to update the second generation in a 3-generation group, replace generation 2, version 0, with generation 2, version 1. Only one version is kept for each generation.
You can catalog a generation using either absolute or relative numbers. When a generation is cataloged, a generation and version number is placed as a low-level entry in the GDG. To catalog a version number other than V00, you must use an absolute generation and version number.
You can catalog a new version of a specific generation automatically by specifying the old generation number along with a new version number. For example, if generation A.B.C.G0005V00 is cataloged and you now create and catalog A.B.C.G0005V01, the new entry is cataloged in the location previously occupied by A.B.C.G0005V00.
|
|
|
| Back to top |
|
|
hchinnam
Active User
Joined: 18 Oct 2006
Posts: 68
|
|
|
|
| Thanks Kevin |
|
| Back to top |
|
|
quanzhong
New User
Joined: 12 Aug 2008
Posts: 37
Location: china
|
|
|
|
Hi superk
thanks. |
|
| Back to top |
|
|
 Moved: Fri Sep 19, 2008 7:21 pm by superk From JCL to SMS & VSAM |
arcvns
Senior Member
Joined: 17 Oct 2006
Posts: 759
Location: Chennai, India
|
|
|
|
Kevin,
Got a bit confused between these....... 
| Quote: |
| Each generation can have 100 versions. |
| Quote: |
| Only one version is kept for each generation. |
Thanks,
Arun |
|
| Back to top |
|
|
Anuj D.
Global Moderator
Joined: 22 Apr 2006
Posts: 2229
Location: Phoenix, AZ
|
|
|
|
Arun,
In GxxxxVyy, "yy" can have values from "00" to "99" so in total 100 differnt versions mathematically, but only one version (in SMS) can exist for a given GDG.
If generation A.B.C.G0005V00 is cataloged and you now create and catalog A.B.C.G0005V01, the new entry is cataloged in the location previously occupied by A.B.C.G0005V00. The old entry is removed from the catalog, to make room for the newer version, and may or may not be scratched depending on what limit processing options are specified for the GDG base.
For SMS DSNs, if scratch is specified, the older version is scratched from the volume. If noscratch is specified, or if the attempt to scratch the DSCB fails, the older version is not scratched and the generation data sets is recataloged as a non-VSAM data set with the GnnnnVnn name not associated with the GDG base.
Try allocating a new "version" for an existing GDG & look the entris in 3.4, things will be rather clear.
For non-SMS DSNs, if noscratch is specified for the base, the older GDS version is not scratched. |
|
| Back to top |
|
|
quanzhong
New User
Joined: 12 Aug 2008
Posts: 37
Location: china
|
|
|
|
Hi, Anuj
now i have a question, in what situation cause to the change of GDG version, update? rename? or other ways.. and want to know GDG version's advantage.. because we seldom see other version but ***v00. |
|
| Back to top |
|
|
dick scherrer
Global Moderator
Joined: 23 Nov 2006
Posts: 8733
Location: 221 B Baker St
|
|
|
|
Hello,
It is probably enough to know that is such a thing as a version. It is not something you are likely to use for your work. I would surely not look for some "problem" that required me to use this "solution".
I don't know that there is any "advantage". It is just a feature - one that is not often used. As you mentioned: "because we seldom see other version but ***v00".
It is probably most important to remember that these are Generation Data Sets and when a new entry is cataloged (+1), this is a new generation  |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 3544
Location: Brussels once more ...
|
|
|
|
| I must admit that in 30+ years on IBM mainframes I can honestly admit to never ever using a version of a GDS. |
|
| Back to top |
|
|
|
|
