|
View previous topic :: View next topic
|
| Author |
Message |
krsenthil85
New User
Joined: 31 Aug 2007
Posts: 55
Location: bangalore
|
|
|
|
Currently I have a job which runs at particular time every day with following steps
Step 1:
1. Merge All GDG versions of File A to a Flat file B.
2. Delete all the existing GDG Versions of A
3. Define a Empty version for GDG A
Step 2:
1. Check the Flatfile B and if is not empty then backup to new GDG C
2. NDM out the Flatfile B and delete it at the end
Now we want to NDM out all the GDG Version of A seperately instead of merging as single file and sending it.
We do not know how many verision of GDG A will be there everyday when this job run. It varies from 0 version to any number everyday. Please let me know how can we adopt this change. |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
Terminology is critical in IT where similar terms may mean very different things. You are not likely to be using versions.
You will need to create a two-step process where the first step determines how many generations (assuming you really meant generations in your post), create JCL with that many steps, and submit the created JCL to the system. The second job will do the transfers.
The current process is simpler to maintain - why does your site think it needs to be changed? |
|
| Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1306
Location: Vilnius, Lithuania
|
|
|
|
| Robert Sample wrote: |
| The current process is simpler to maintain - why does your site think it needs to be changed? |
<cynical mode>
More jobs == higher charge-out?
</cynical mode> |
|
| Back to top |
|
|
RahulG31
Active User
Joined: 20 Dec 2014
Posts: 446
Location: USA
|
|
|
|
My idea is that you'll be sending separate files in separate steps. So, you will have each gdg file referred in the step as generation 0, -1, -2, .. etc.
You may write the maximum number of steps (=max number of generations) and when any generation is not found then the JCL will give error and will stop there.
Another approach is that you can first check whether the generation exists or not (through IDCAMS) and then proceed depending on the return code of IDCAMS step.
. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| RahulG31: if the site uses JES3 your first approach will not work as a JCL error for data set not found will occur. |
|
| Back to top |
|
|
krsenthil85
New User
Joined: 31 Aug 2007
Posts: 55
Location: bangalore
|
|
|
|
| prino wrote: |
| Robert Sample wrote: |
| The current process is simpler to maintain - why does your site think it needs to be changed? |
<cynical mode>
More jobs == higher charge-out?
</cynical mode> |
Because the customer wants to recieve the file individually on their mailbox instead of a combined file. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| In that case, you'll need to use IDCAMS (or whatever similar tool is used at your site), parse the output to identify the different generations, and submit the created JCL to the internal reader. It won't necessarily be a complicated process, but you will have to handle the no generations situation as a special case, probably -- you need at least one executable step in a job. |
|
| Back to top |
|
|
Pete Wilson
Active Member
Joined: 31 Dec 2009
Posts: 581
Location: London
|
|
|
|
| why not just have an NDM step following the one that creates the GDS in the first place? |
|
| Back to top |
|
|
|
|
