Can SORT identify the Relative GDG version?

santoshkumarmanilakkoju · Posted: Fri Apr 04, 2014 8:05 pm

Hi All, Do we have any SORT utility which can identify a Relative GDG version?

Example : ABC.EFG.XYZ(-1) when given as Input should give a relative GDG version as GnnnnV00 n being any relative numeric.

dbzTHEdinosauer · Posted: Fri Apr 04, 2014 8:20 pm

do you want generation or version?

also, 0, -1, -2 etc are the relative gens.
what you want - GnnnnV00
is the absolute.

there are many examples of parsing a dslist or an idcams listing of a GDG file inorder to determine the name of the absolute, refered to by the relative.

since the absolute name today of relative -1 would/more than likely be different from that of tomorrow or yesterday (on a file created daily),
you could create a little tool that would provide the answer.
otherwise, you can always display the dslist of a GDG file and visually find the answer.

a direct answer to your question, i do not know of any utility (SORT is itself a utility) that directly provides a simplistic answer.

I imagine the ops-sys itself does a dslist (or similar) of a GDG file and performs the necessary parsing dependent on the relative number provided - as in JCL DSN(0), or DSN(+1), or DSN(-1).

Nic Clouston · Posted: Fri Apr 04, 2014 9:14 pm

What did you find in the sort manuals relating to this?

steve-myers · Posted: Fri Apr 04, 2014 10:34 pm

The relative generation as specified in JCL is available in the JFCB, but I doubt if any of the sort products actually look there. Why do you think it would be useful?

Skolusu · Posted: Fri Apr 04, 2014 11:23 pm

santoshkumarmanilakkoju · Posted: Mon Apr 07, 2014 12:34 pm

My Requirement -->

I need to compare few versions of a GDG Base to the current version and identify duplicate version. Once it is identified pull that version and display it.

Example :

ABC.XYZ is the base and I have below versions -

ABC.XYZ(-3) Generation G0007.V00
ABC.XYZ(-2) Generation G0008.V00
ABC.XYZ(-1) Generation G0009.V00
would be compared Record by Record (in a SORTED format) with
ABC.XYZ(+0)

If any of the prior verisons are a match to current version display that GENERATION.

Say (-2) is a match to (+0), then display ABC.XYZ.G0008.V00

Nic Clouston · Posted: Mon Apr 07, 2014 1:15 pm

Those are not 'versions' they are generation datasets (or generations for short). If they were versions then the Vxx portion would change whilst the generation portion would remain fixed e.g. G0008V00 and G0008V01 are versions of generation 8.

As it is you have incorrectly specified the dataset names - there is no dot between the generation number and the version number - G0008V00 not G0008.V00

santoshkumarmanilakkoju · Posted: Mon Apr 07, 2014 3:32 pm

Sorry for all the typos..

dbzTHEdinosauer · Posted: Mon Apr 07, 2014 3:58 pm

Santosh,

you are looking for GENERATIONS that are the same. NOT VERSIONs.

Terminology is very important.

Though there are ways to derive the absolute DSN from a relative DSN
(DSN = Dataset Name)
I would suggest that you not invest the time to incorporate the necessary code. Though it would be simple.
Use SORT to perform the compare (or a COBOL program - or any language)
and simply output a record - GEN -1 not equal (or equal) to GEN 0.
The relative GEN (-1,-2 etc...) would be an input parm to the compare program,
so that the necessary message could be generated (not to be confused with GDG).

You would build your JCL to have several STEPs that would perform the compare (each generating a message). The output record would/could/should be written to a GDG (the why? read below.)

the last step of your job would generate a dslist of the compared GDG.
the program would determine the absolute name of each relative file existing.
As input, this program would read the GDG base containing the messages generated by each compare step.
upon finding an equal message, the last step program would substitute the absolute name for the relative and output a message for each.

compare message datatset as GDG? so the last step program could simply have constant - the message DSN as base, so the last step program would not need to know how many compare steps were executed.

obviously, the job should first delete all existing files for the message dataset.
yes, you could also use a regular file and then MOD the output.

by the way, literal reading of your requirement is problematic, because
your usage of terminology is so poor.

santoshkumarmanilakkoju · Posted: Mon Apr 07, 2014 4:14 pm

Thanks dbz. That is very helpful in constructing a solution.

One qq though. Is their a way to compare multiple files with one file (say A) and write out the file which is duplicate to A. All this using ONE SORT step?

daveporcelan · Posted: Mon Apr 07, 2014 6:39 pm

This is a typical example of how many threads go on this forum.

Rant on...

OP asks very generic question using incorrect terminology. This displays either carelessness, or a lack of understanding of their profession.

Several experts answer their question, providing a lesson to correct their mistake.

One expert even asks the silly question regarding reading the manual.

OP responds with their requirement (why didn't they do that in the first place)? This requirement still contains incorrect terminology and syntax.

Once this is pointed out by an expert, OP responds with an eyeroll. Moderator, please delete and ban user at this point. Some nerve.

An expert trudges on, formulating a detailed explanation for a solution to this requirement. The solution says in no uncertain terms that several steps are required.

OP shows ever more nerve, by giving a terse thank you, but asking if this can be done in ONE SORT step.

Santosh, get a grip here. People on this forum are putting in a great deal of effort to help you. You on the other hand do nothing to help yourself. You have not displayed an understanding of the difference between Generation and Version. You literally roll your eyes when responding to being corrected. You dismiss a detailed solution, by asking if it could be done in ONE SORT step. If it could be done, would Dick (dbz) have given such a detailed multi step solution?

Go back and meditate of what it takes to succeed in this industry, and how to ask and receive help.

Rant off

Bill Woodger · Posted: Mon Apr 07, 2014 9:16 pm

Dave,

It think it is worse than that. It seems one generation contains entirely duplicate data to the current generation, and TS/OP is looking for an easy (for them) way to find which generation it is (easy does not, for some reason, include looking at the sysout of the jobs which create new generations, or anything like that).

Let's say about 1m records per generation, 20 generations, and just something to toss into the machine which is going to read the current generation 19 times and each of the other generations once, record-per-record, to identify similarity.

Nuts.

Santosh, why can't you read the sysouts?

Why can't you do it "by hand"? It's a one-off task? Could have been done long ago.

If you really want to get the computer to do it (after all, you're not paying for the CPU time, and other resources, are you?) write a program. One DD for (0), one DD for each of your other generations. Read first record on all files. Compare. Stop processing each file as a difference is found. As soon as there is only one file left, you have your duplicate (assumes there is an actual duplicate).

No, SORT is not a good solution for this. No-one is going to write SORT control cards for you for such a "requirement".

Bill Woodger · Posted: Mon Apr 07, 2014 9:23 pm

I'm locking the topic. Santosh, if we have misunderstood your requirement, you can click on the Locked button and explain fully and clearly, including how it got that way, what is the process which creates the generations, etc. Everything.