Currently We are getting a PDS with one member name called “BINDS”. This will list many names starting from the position 1 and can be up to 8 characters.
PDS NAME -> XXXX.XXXX.XXXX
Member name -> BINDS
ABCDEHG1 -- Record 1
ABCDEHG2 -- Record 2
ABCDEHG3 -- Record 3
ABCDEHG4 -- Record 4
ABCDEHG5 -- Record 5
ABCDEHG6 -- Record 6
ABCDEHG7 -- Record 7
We are making use of One COBOL program which will read above PDS member (BINDS) as INPUT and create the below JCL cards and write into a sequential file.
The Output sequential file then put into “INTRDR “ so that it submits all the jobs created by the Cobol programs in sequence.
YYYYYY.YYYYYYY.YYYYY is PDS and after all jobs have completed we get the BINDS cards for all the elements which will be stored as members.
ABCDEHG1 -- Member 1
ABCDEHG2 -- Member 2
ABCDEHG3 -- Member 3
ABCDEHG4 -- Member 4
ABCDEHG5 -- Member 5
ABCDEHG6 -- Member 6
ABCDEHG7 -- Member 7
All the members will have the cards as shown in the above JCL.
Now the problem is we are getting nearly 50000 members many times and we end up in submitting 50000 jobs. We also tried to update nearly 200 Steps for single JCL and then submit for INTRDR but still not able to reduce the number of jobs we are submitting.
To handle this scenario we really could not think of any other alternative with our limited knowledge.
Wanted to know from experts if there is a way to handle this scenario using one single job.
Please let me know if you want any additional information. Any help would be greatly appreciated.
I also searched the forum but not found anything similar.
Joined: 20 Oct 2006 Posts: 6968 Location: porcelain throne
In one TMP (ikjeft..) step you only need one DSN and you can umteen number of BINDS. but that would require changing your whole process - which you should. Most places do this dynamically, based on the db2 catelogue and not some file (pds member with bind names).
others are better skilled at suggesting methods that you can employ, so I will sign off with this warning:
Watch out that you don't blow your db2 catelogue during the process of 'binding/rebinding' everything.
Thank you for the suggestion. Our process we create Binds cards in one dataset and copy them to many regions after making modifications in the BIND parameters as region specific. Finally perform Binds.
I agree that implementing your suggestion requires many process changes.
I have also gone through forum and seen some of the posts. Looks like REX can be used to build a logic for my need (I may be wrong since I am new to REX). Never used to REX so doing some trial and error method and reading manuals if this can be achievable. Sorry but still clueless how this can be handled.
Joined: 01 Dec 2006 Posts: 683 Location: Pennsylvania
I appears to me that you are making this much more complicated than it needs to be.
As Dick mentioned, you can perform many Binds using a single file in a single job step.
I have done 5000 or more without any catalog issues. Check with your DBA staff regarding that.
Given the fact that you have to make some sort of changes, it would probably easiest to change your Cobol program:
Create One sequential file (not PDS) for each DB2 Subsystem.
Each of these files can have ALL the Binds for all the regions with the specific parameters for each. Your program is already doing this.
You only need a single DSN SYSTEM(DB2SYS) at the top of each.
You can then run one Bind job with seperate steps for each subsystem.
Or one Job per subsystem, even creating JCL and using the internal reader if you like.
Creating a dynamic REXX (two xx's), can certainly be done. I have created a process to do just that. It would be very involved, not for the Rexx novice, and certainly could not be explained through a forum such as this.
I would go with modifying the Cobol approach you currently have in place.
Thank you for your Valuable inputs. After speaking with the DBA's they disagreed the suggestion to do all Binds in One step and want us to stick to 1 BIND at a time. By having all binds at one step they say we may cause problems with catalog and result in utilizing DB2 resources heavily resulting in contentions.
So trying to come up some thing in REXX since you all said it is possible in REXX.