Hi..I am new to rexx and looping..I am trying to build a JCL using SORT BUILD. The sort mentioned above is in a loop. The issue that i am not able to resolve is how can I get the GDG version and the job name incremented in the JCL.
> Using ICETOOL to get the count from a previous step
> Using the count in REXX to loop and submit jobs depending on the count
> The program in the job takes GDG versions as input
> I want to make the job card and the GDG version dynamic based on the count that i get from STEP 1.
This is the second JCL. Here in CLMFILEI, I want to use the loop’s counter from the previous job. Also, if possible, the 2nd job’s jobname dynamic so that I can run these in parallel.
You were specifically asked to use the code tags when presenting what you have tried - you did not. Done for you THIS TIME. Do it yourself in future.
Joined: 10 May 2007 Posts: 2454 Location: Hampshire, UK
Clear as mud - but why not have a Rexx program that reads in the count, loops count times producing count jobs?
Why does your IEFBR24 have SYSOUT and SYSIN? iEFBR14 does noting - reads nothing and writes nothing so needs no DD Names.
Presumably you mean 'generations' not 'versions'? 'versions' relate to the verion number that comes after the V (for Version) in GxxxxVyy.
Another thing - your topic title is 'Looping in JCL'. 2 things wrong here. 1 - JCL has no loop facility and, 2 - what you are talking about seems to be something completely different.
Thanks for helping me out with the code tags. Will keep that in mind in the future.
Why does your IEFBR24 have SYSOUT and SYSIN? iEFBR14 does noting - reads nothing and writes nothing so needs no DD Names.
Presumably you mean 'generations' not 'versions'? 'versions' relate to the verion number that comes after the V (for Version) in GxxxxVyy.
Another thing - your topic title is 'Looping in JCL'. 2 things wrong here. 1 - JCL has no loop facility and, 2 - what you are talking about seems to be something completely different.
IEFBR14 was just set to identify which generation gets generated at which sequence. It serves no purpose. Was used only for testing.
Looping in JCL is not possible. But I wanted to submit a job by incrementing a few variables. The jobcard in the second job has to get dynamically defined and also the input file of the second job takes the versions of the GDG.
but why not have a Rexx program that reads in the count, loops count times producing count jobs?
any examples that i could use. I am not able to visualize it. Sorry.
Thanks for helping me out with the code tags. Will keep that in mind in the future.
Why does your IEFBR24 have SYSOUT and SYSIN? iEFBR14 does noting - reads nothing and writes nothing so needs no DD Names.
Presumably you mean 'generations' not 'versions'? 'versions' relate to the verion number that comes after the V (for Version) in GxxxxVyy.
Another thing - your topic title is 'Looping in JCL'. 2 things wrong here. 1 - JCL has no loop facility and, 2 - what you are talking about seems to be something completely different.
IEFBR14 was just set to identify which generation gets generated at which sequence. It serves no purpose. Was used only for testing.
Looping in JCL is not possible. But I wanted to submit a job by incrementing a few variables. The jobcard in the second job has to get dynamically defined and also the input file of the second job takes the versions of the GDG.
but why not have a Rexx program that reads in the count, loops count times producing count jobs?
any examples that i could use. I am not able to visualize it. Sorry.
Absolute mess; even worse than the original post...
Before coding anything, please, try to explain in plain English: what is your goal, at all???!!
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
Quote:
I want to run all those jobs parallel but not able to as the job names are the same and the files are getting held up.
Have you discussed this with your site support group? Many sites limit the number of jobs for different job classes, and if you're running your jobs in such a job class, JES will limit the number of jobs that can run in parallel -- even if the job names are all unique.
Issue- I have a file that contains distinct filenames. Each filename needs to be passed to a different job that will call a COBOL program. Based on the count of distinct filenames, the REXX program will loop and call the second JCL, that contains the COBOL program.
Each version of the GDG will contain 1 of the filenames. These filenames will be passed to the DD statement of the COBOL step in the second JCL.
Requirement-
The first job will call the second JCL N times (N being the number of distinct files). This part has been completed. The part where I am stuck at is the point where I am not able to autoincrement the GDG version number in the second JCL. I want the second JCL to read the subsequent versions based on the counter.
The other issue that I am encountering is that I am not able to put different jobnames in the job card. The second JCL is getting triggered N times, but due to name contention, its getting held.
I am preparing the JCL's using sort build and passing the count from the input file.
I apologize if I am not clear as its my first time approaching a problem like this.
Joined: 10 May 2007 Posts: 2454 Location: Hampshire, UK
I understand that you have a dataset (not a file) which, itself, contains a list of dataset names. Theses datasets have to be processed by a cobol program in a job - a separate job for each dataset.
Where does this list of dataset names come from? Why can the scheduler not submit the appropriate job to process the dataset when that dataset is created? Schedulers can do this.
I am getting the datasets name as an output of a cobol program. This cobol program reads a table and fetches the dataset names based on a query. These datasets are varying and not always fixed and due to this, the entire thing has to be dynamic.
Same cobol program for each dataset, yes.
A fixed number of filenames wouldn't have been an issue..
Using the SORT utility to dynamically create temporary REXX code, and to substitute loop limit as a constant - it's the top of senseless activity I've ever seen in my life.
JCL code cannot be "called" at all, especially "called from another JCL code". This is absolute bullshit. Any JCL can only be submitted.
1) Use once-prepared REXX code which takes the list of required datasets from its input (and easily counts them, without any parameter).
2) Within this REXX code, dynamically re-allocate every new dataset name with the same DD name, and dynamically call the required COBOL module form this internal REXX loop.
Joined: 10 May 2007 Posts: 2454 Location: Hampshire, UK
Seems like a simple rexx program that reads a dataset name from the input dataset, generates a job id, input dataset and output generation and then updates a skeleton JCL, submits it and then reads the next dataset name and repeats the process.
I understand it would be very simple but it's the first time i am working on something related to rexx and noone in my group is aware of all the functionalities
Any examples please? I checked the other pages in the forum but wasn't able to get it.. i am new to rexx so need some guidance..
This group supposed to clarify some tricky moments to the people who have seen mainframe more than once in their life, and not only to play computer games.
If you actually have no idea about designing, coding, and debugging algorithms (whatever language/tool is used, it doesn't matter) - then you need two steps first of all:
1) attend training classes, like "Basic Principles of Software Development"
2) visit the parallel Beginners Forum for mainframers.
Joined: 10 May 2007 Posts: 2454 Location: Hampshire, UK
Also: skim-read the Rexx Language Reference manual (you will not need most of it for this problem), refer to z/OS TSO/E REXX User's Guide for info on EXECIO and z/OS ISPF Dialog Developer's Guide and Reference for information on file tailoring.
Also, chat to your system programmers - they are probably fluent in Rexx.
Joined: 01 Sep 2006 Posts: 2594 Location: Silicon Valley
note: I have never used GDGs! But I recall something about the value of the current generation is not updated until after the job is completed (or something like that)
I do not think you can build a job then build another job and have it use a different generation. If I were you, I would not use a GDG at all. If you are building the JCL yourself, just use a data set name where the name contains the date, the time and a sequence number. Increment the sequence number for each iteration of the loop.
the value of the current generation is not updated until after the job is completed
is true, the way around is to increase the number during the job, i.e.
step1 use gdg.dsn(+1)
step2 use gdg.dsn(+2)
etc.
I have used GDGs a lot and I like them, mostly because they are self-cleaning - obsolete datasets are automatically deleted. But yes there are drawbacks too.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
Now this is what goes on with Generation Data Group (GDG) data sets.
First, the programmer creates a GDG index. A GDG index can contain up to 35 characters. When you create the index you specify a few attributes about the index. The most important attribute is the maximum number of data sets within the index that can be created at any time. In traditional GDG indexes you can retain up to 255 data sets. Now you can create “extended” indexes to retain as many as 999 data sets.
In these examples, we will use a GDG index as simply GDG.
In JCL, to add a new generation data set (to use the official terminology) to the index you specify a data set name as DSN=GDG(+n) where n is usually 1 or 2, rarely more. You specify an existing generation as DSN=GDG(0) or GDG(-n). GDG(0) retrieves the most recently added generation, GDG(-1) and so on. In my work, for example, I have one GDG that retains 20 generations. Yesterday a job created absolute generation 2123 and automatically deleted absolute generation 2103 to make room for the new data set; the JCL just specified DSN=GDG(+1). Within one job, the mapping of relative generation to absolute generation is fixed. After the job completes GDG(0) retrieves the GDG(+1) from the previous job. This mapping of relative generations to absolute generations means that no other job that uses relative generations can run in parallel with another job that uses relative generations of the same generation data group.
Now Mr. Jensen mentioned there are some drawbacks to using GDGs. Before the advent of System Managed Storage a programmer had to create a data set with default DCB attributes for the GDG, or go through moderately strange JCL when creating a new member of the GDG. Many shops applied a rather non-standard and unsupported modification to the MVS job scheduler to bypass this requirement. There are other issues I won’t try to discuss here.
