Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Can SORT identify the Relative GDG version?

 
Post new topic   This topic is locked: you cannot edit posts or make replies.    IBMMAINFRAMES.com Support Forums -> DFSORT/ICETOOL
View previous topic :: :: View next topic  
Author Message
santoshkumarmanilakkoju

New User


Joined: 24 Nov 2009
Posts: 37
Location: Don't know

PostPosted: Fri Apr 04, 2014 8:05 pm    Post subject: Can SORT identify the Relative GDG version?
Reply with quote

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

dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Fri Apr 04, 2014 8:20 pm    Post subject:
Reply with quote

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

Global Moderator


Joined: 10 May 2007
Posts: 1715
Location: UK

PostPosted: Fri Apr 04, 2014 9:14 pm    Post subject: Reply to: Can SORT identify the Relative GDG version?
Reply with quote

What did you find in the sort manuals relating to this?
Back to top
View user's profile Send private message
steve-myers

Active User


Joined: 30 Nov 2013
Posts: 461
Location: The Universe

PostPosted: Fri Apr 04, 2014 10:34 pm    Post subject:
Reply with quote

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

Senior Member


Joined: 07 Dec 2007
Posts: 2205
Location: San Jose

PostPosted: Fri Apr 04, 2014 11:23 pm    Post subject: Re: Can SORT identify the Relative GDG version?
Reply with quote

santoshkumarmanilakkoju wrote:
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.


As dbz pointed out you need the absolute number of the GDG generation.

The question why do you need it for?

Either way they are a couple of DFSORT smart tricks that you may want to take a look at

Report on GDG base limits
Copy GDGs created today
Copy GDG records in first in, first out order

http://www.ibm.com/support/docview.wss?uid=isg3T7000094
Back to top
View user's profile Send private message
santoshkumarmanilakkoju

New User


Joined: 24 Nov 2009
Posts: 37
Location: Don't know

PostPosted: Mon Apr 07, 2014 12:34 pm    Post subject:
Reply with quote

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

Global Moderator


Joined: 10 May 2007
Posts: 1715
Location: UK

PostPosted: Mon Apr 07, 2014 1:15 pm    Post subject: Reply to: Can SORT identify the Relative GDG version?
Reply with quote

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

New User


Joined: 24 Nov 2009
Posts: 37
Location: Don't know

PostPosted: Mon Apr 07, 2014 3:32 pm    Post subject: Reply to: Can SORT identify the Relative GDG version?
Reply with quote

Sorry for all the typos..
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Mon Apr 07, 2014 3:58 pm    Post subject:
Reply with quote

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

New User


Joined: 24 Nov 2009
Posts: 37
Location: Don't know

PostPosted: Mon Apr 07, 2014 4:14 pm    Post subject:
Reply with quote

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

Active Member


Joined: 01 Dec 2006
Posts: 645
Location: Pennsylvania

PostPosted: Mon Apr 07, 2014 6:39 pm    Post subject:
Reply with quote

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

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7232

PostPosted: Mon Apr 07, 2014 9:16 pm    Post subject: Reply to: Can SORT identify the Relative GDG version?
Reply with quote

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

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7232

PostPosted: Mon Apr 07, 2014 9:23 pm    Post subject: Reply to: Can SORT identify the Relative GDG version?
Reply with quote

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.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   This topic is locked: you cannot edit posts or make replies.    IBMMAINFRAMES.com Support Forums -> DFSORT/ICETOOL All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Limit duplicate records in the SORT pshongal SYNCSORT 6 Mon Nov 21, 2016 12:54 pm
No new posts How to convert the VBM file to VB or... Sulabh Agrawal JCL & VSAM 4 Fri Nov 18, 2016 1:04 pm
No new posts COBOL Version 6.1 Virendra Shambharkar COBOL Programming 5 Tue Nov 01, 2016 11:24 am
No new posts Sort records based on numeric field. Alks SYNCSORT 2 Wed Oct 19, 2016 10:14 pm
No new posts How to delete second instance from Fl... Gunapala CN DFSORT/ICETOOL 6 Tue Oct 18, 2016 11:42 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us