IBM Mainframe Forum

Posted: **Thu Aug 14, 2014 3:30 pm**

Hi,

My requirement is, I need to search for a string in all GDG generations(appx 100).
The string is at a specific position.

Is there a way that the search should start from (Latest Gen - 1) up to oldest generation present ???

Is there a way I can get the Generation name in which the string is present ???

I have a working code which searches from the latest gen to oldest gen, and copies the records corresponding to the string to output file.
But I can't know in which gen it's present.

Select all

//STEP1 EXEC PGM=SYNCSORT
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SORTIN DD DSN=MY-GDG-BASE,
// DISP=SHR
//FILE1 DD DSN=OUTPUT-FILE-HAVING-RECS-WITH-MY-STRING,
// DISP=(NEW,CATLG,DELETE),
// DCB=*.SORTIN,
// SPACE=(CYL,(3,300))
//SYSIN DD *
SORT FIELDS=COPY
OUTFIL FNAMES=FILE1,INCLUDE=((8,9,CH,EQ,C'MY-STRING1'),OR,
(8,9,CH,EQ,C'MY-STRING2'),OR,
(8,9,CH,EQ,C'MY-STRING3'))
/*

Posted: **Thu Aug 14, 2014 4:01 pm**

Sorry about the topic name. It's a Syncsort query.

Posted: **Thu Aug 14, 2014 10:38 pm**

No, you can't magically get the DSN of the current input.

Is this a once-off task? Is there a header or trailer on the files? If yes, you can use WHEN=GROUP to set an ID for the header (or trailer) and include the ID in the output, from which (by manual calculation) you could locate which file the output was sourced from.

If there are no headers/trailers, then the only thing you can do with SORT is generate a dummy header, specify each DSN of the GDG on a concatenation to SORTIN and itersperse each with the dummy header.

Posted: **Mon Aug 18, 2014 5:46 pm**

Thanks BillyBoyo.

Magic didn't happen by itself. However, I was able to get the header record which had DATE printed.
As only 1 file is created per day, I can easily point out the generation now.

There is a problem which still persists.

When I specify some generations(complete dsn), the sort runs like a charm. However, when I specify the GDG base dsn only, the job gets stuck.
No "sysout" on spool. No "waiting for resources". Just the job in EXECUTION status. <b>Any idea ???<b>

Can you tell me specifying the GDG base is a "wildcard", or some "take generations from this base" - instruction in JCL ??
I mean, will specifying the GDG base only pick up any dataset with dsn "gdg-base.dt081814" ???

Is it a basic concept I am missing ?!!

Posted: **Mon Aug 18, 2014 8:04 pm**

If you have one DD working how you want, the other should work in the same way.

It is difficult without seeing the actual JCL, and the output, to work out why this is happening, as it shouldn't be if as you describe,

I think it's something you'll have to run pas your technical support people.

Posted: **Tue Aug 19, 2014 2:41 pm**

Thanks a ton BillyBoyo.

Here is what was happening.

The JCL, prior to actually start executing(and printing SYSOUT... in spool), was recalling all the GDG generations. and THAT TOOK TIME(I thought the job got stuck).
Today it took almost 1 hour just to recall all the gens ( as they are pretty big I guess), and then I saw all the read counts in spool.
It ran almost 1.5 hour, then it completed successfully.

So, the JCL and syntax are fine . . .It's just what they are dealing with matters as well.

And about:

Can you tell me specifying the GDG base is a "wildcard", or some "take generations from this base" - instruction in JCL ??
I mean, will specifying the GDG base only pick up any dataset with dsn "gdg-base.dt081814" ???

The dsns like "gdg-base.dt081814" or "gdg-base.G032.bkp" won't get picked up by the job. This I observed as some like datasets were still migrated after the job was run and all the actual gdg gens were recalled and I could see the read-dataset list in the spool.

Posted: **Tue Aug 19, 2014 3:40 pm**

This relates to a previous question I asked. Whatever you may do on your own computer, you don't just go searching for things without thinking of a better way to do it first. This is a Mainframe, and it is quite possible to incur considerable cost (for someone) if you do such things. If you "grep" your own harddisk, you've already paid for everything, and other than electricity and perhaps reducing the usable life of your HDD, there is no further cost.

This need not be so on the Mainframe.

The best way to look for data is not to lose it in the first place.

So, exactly, what are you trying to do (I assume it is not "to run up a huge cost for someone somewhere")?

Posted: **Tue Aug 19, 2014 5:55 pm**

BillyBoyo wrote:So, exactly, what are you trying to do (I assume it is not "to run up a huge cost for someone somewhere")?

Well. That was only once I "waited" to see how long it takes. Won't try it again. :roll:

Instead, I will check in only few generations(maybe 1) where the possibility of getting the data is more(as per business logic).

IBM Mainframe Forum

Search a string in all GDG generations

Search a string in all GDG generations

Re: Syncsort - Search a string in all GDG generations

Re: Search a string in all GDG generations

Re: Search a string in all GDG generations

Re: Search a string in all GDG generations

Re: Search a string in all GDG generations

Re: Search a string in all GDG generations

Re: Search a string in all GDG generations