Author: Akatsukami
Posted: Sat Mar 04, 2017 10:44 pm (GMT 5.5)
Well, there are several problems with your post.
The low-level qualifier (LLQ) that you specify is invalid. A generation data set's LLQ will be of the form GnnnnVmm, where nnnn, the generation number, varies from 0001 to 9999. A GDS is generally referred to by a relative generation number; the JCL might specify something like:
where "(+1)" is interpreted "one greater than the highest existing generation". Thus, a given run of this job might find FOO.BAR.G0100V00 to be the highest existing generation and create FOO,BAR.G0101V00; the next run, of course, finding G0101V00, would create G0102V00. A GDS created in this way always has a version number (the "Vmm" part) of V00; only if the GDS is referred to with an absolute generation number (E.G., as FOO.BAR.G0102V01) will be the version number be different; this is often (but not invariably) done to indicate that the data set was recreated in a restart or rerun.
Now, given that z/OS provides this sophisticated mechanism, why do you want to replace it with a RYO naming scheme? This might be appropriate in a more primitive OS as Unix or Windows where GDGs are unavailable, but I do not see what you hope to gain from it in a mature environment such as z/OS provides. Please explain your reasoning, and we'll see if we can't come up with a realistic alternative.
_________________
Data is not information.
Information is not knowledge.
Knowledge is not wisdom.
Posted: Sat Mar 04, 2017 10:44 pm (GMT 5.5)
Well, there are several problems with your post.
The low-level qualifier (LLQ) that you specify is invalid. A generation data set's LLQ will be of the form GnnnnVmm, where nnnn, the generation number, varies from 0001 to 9999. A GDS is generally referred to by a relative generation number; the JCL might specify something like:
| Code: |
| //OUT1 DD DSN=FOO.BAR(+1),DISP=(,CATLG,DELETE),... |
where "(+1)" is interpreted "one greater than the highest existing generation". Thus, a given run of this job might find FOO.BAR.G0100V00 to be the highest existing generation and create FOO,BAR.G0101V00; the next run, of course, finding G0101V00, would create G0102V00. A GDS created in this way always has a version number (the "Vmm" part) of V00; only if the GDS is referred to with an absolute generation number (E.G., as FOO.BAR.G0102V01) will be the version number be different; this is often (but not invariably) done to indicate that the data set was recreated in a restart or rerun.
Now, given that z/OS provides this sophisticated mechanism, why do you want to replace it with a RYO naming scheme? This might be appropriate in a more primitive OS as Unix or Windows where GDGs are unavailable, but I do not see what you hope to gain from it in a mature environment such as z/OS provides. Please explain your reasoning, and we'll see if we can't come up with a realistic alternative.
_________________
Data is not information.
Information is not knowledge.
Knowledge is not wisdom.