Generating JCL with REXX
Jim Farland
Can REXX dynamically generate JCL for COBOL DDNAMES using some sort of
a lookup process? I want to generate JCL with unique filenames that
come from a static lookup table.
For example:
2 reports need to be generated one for company A and one for Company B
There is one input file containing the data for both Company A and
Company B
A parameter is passed to REXX to find the proper output filename.
REXX does a lookup to a static table to find the first 10 bytes of the
output filename and concatenates the last byte with the company value
("A" or "B").
REXX then generates the rest of the needed JCL to allocate the output
file names for Company A and Company B.
Can this hypothetical scenario be done using REXX?
Thank you for any suggestions in advance;
Jim Farland
William Lightner
The short answer is "yes".
A slightly longer answer would be that this would require submitting the
resultant JCL as a separate job. If this is acceptable.
A slightly different approach would be to do ALLOCs from the REXX for
the COBOL program, as required for the program, and then start the COBOL
program directly from REXX.
I haven't done this, because I've never, in the final analysis, had the
need. It seems to me that what you actually need is a second program to
redirect the outputs from the first, according to need, and possibly
with a parameter to tell it which it is doing...?
Does this help?
William Lightner
Shmuel (Seymour J.) Metz
at 07:58 PM, farla...@netscape.net (Jim Farland) said:
>Can REXX dynamically generate JCL for COBOL DDNAMES using some sort
>of a lookup process? I want to generate JCL with unique filenames
>that come from a static lookup table.
There's nothing special about JCL. You can submit a job by writing to
an internal reader. In practice, it may be less work to use ISPF Table
Services rather than doing it directly in REXX.
--
-----------------------------------------------------------
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2
Team OS/2
Team PL/I
Any unsolicited commercial junk E-mail will be subject to legal
action. I reserve the right to publicly post or ridicule any
abusive E-mail.
I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me. Do not reply to
spam...@library.lspace.org
-----------------------------------------------------------
Stuart Grace
I'm not sure from your description if your program would run once for each
company or once for all.
Some options you have are to set up a PROC that has variables and the JCL
would execute the PROC with variables for each company. You could have a
job that has a step for each company.
You could have a interactive REXX program generate the JCL and use the TSO
submit command.
An ISPF dialog could take the input and use file tailoring with skeleton
files.
Your REXX program could allocate files and then link or attach your
program. REXX can be run in batch.
Ian
command to stack up 'change all' commands, or use file tailoring to set
values for symbolic variables before, in either case, submitting the jobs.
Of course, for more fun, you could write the reports using Rexx too, and
then email them to a list of recipients, bypassing the need for system
output files altogether!!
Ian
Jim Farland
the best solution. Do you have any examples?
Thank you in advance;
Jim Farland
Stuart Grace <Nstu...@Ous.Sibm.PcomAM> wrote in message news:<3B2F5F3E...@Ous.Sibm.PcomAM>...
Jim Farland
> An ISPF dialog could take the input and use file tailoring with skeleton
> files.
>
Stuart Grace <Nstu...@Ous.Sibm.PcomAM> wrote in message news:<3B2F5F3E...@Ous.Sibm.PcomAM>...
Steven Hughes
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ispser04/CCONTENT
S
Essentially you need to put skeleton JCL into a member in your ISPSLIB
dataset and run
FtOpen, FtIncl <member> and FtClose services from your REXX.
HTH,
Steven.
Jim Farland wrote in message
<25aa81ec.01062...@posting.google.com>...
Shmuel (Seymour J.) Metz
at 12:19 PM, "Steven Hughes" <sjhu...@eircom.net> said:
>Essentially you need to put skeleton JCL into a member in your
>ISPSLIB dataset and run
First, you probably aren't allowed to and seceond, you shouldn't. Put
the skeleton into your own library and use LIBDEF.
Steven Hughes
Shmuel (Seymour J.) Metz wrote in message
<3b35f5ef$2$fuzhry$mr2...@va.news.verio.net>...
>In <PX_Y6.10428$Fk7....@news.indigo.ie>, on 06/23/2001
> at 12:19 PM, "Steven Hughes" <sjhu...@eircom.net> said:
>
>>Essentially you need to put skeleton JCL into a member in your
>>ISPSLIB dataset and run
>
>First, you probably aren't allowed to and seceond, you shouldn't. Put
>the skeleton into your own library and use LIBDEF.
>
Excuse me? I have a logon script that concatenates my ISP datasets ahead
of the system supplied ones. I LIBDEF when I distribute, not when I'm
testing.
Shmuel (Seymour J.) Metz
at 08:17 PM, "Steven Hughes" <sjhu...@eircom.net> said:
> Excuse me? I have a logon script that concatenates my ISP
>datasets ahead of the system supplied ones. I LIBDEF when I
>distribute, not when I'm testing.
Concatening your own library at logon time is fine. Putting your
skeleton into the ISPSLIB dataset (ISP.SISPSENU?) is not.
Steven Hughes
Shmuel (Seymour J.) Metz wrote in message
>In <Oe5_6.11419$Fk7.1...@news.indigo.ie>, on 06/26/2001
> at 08:17 PM, "Steven Hughes" <sjhu...@eircom.net> said:
>
>> Excuse me? I have a logon script that concatenates my ISP
>>datasets ahead of the system supplied ones. I LIBDEF when I
>>distribute, not when I'm testing.
>
>Concatening your own library at logon time is fine. Putting your
>skeleton into the ISPSLIB dataset (ISP.SISPSENU?) is not.
>
DDNAME.
Is that better?
Shmuel (Seymour J.) Metz
at 08:30 PM, "Steven Hughes" <sjhu...@eircom.net> said:
> OK, wrong choice of words. I meant dataset concatenated to
>ISPSLIB DDNAME.
> Is that better?
Much. It's something that a lot of shops do automatically.
J. Turincs
1. Define a new ISPSLIB similiar to ISPENU - if you issue the command "TSO
ISRDDN", find a file in your ISPSLIB concatenation, and copy the attributes
for your new file (this is important because some shops use all variable
files and some use all fixed).
2. Edit a new member for your skeleton, say MYSKEL
3. Issue a LIBDEF and ALTLIB activate during testing
4. Once completed, you should have a REXX exec which performs
FTOPEN
FTINCL MYSKEL
FTCLOSE
5. Ensure your REXX exec is located in the SYSPROC or SYSEXEC concatenation
6. If you include a ISPF panel to gather the necessary input, then this
should be concatenated into the ISPPLIB (use same procedure above to define
a separate application library if necessary).
...
HTH,
j. turincs
eMerging Technolgies, Inc.
"Shmuel (Seymour J.) Metz" <spam...@library.lspace.org.invalid> wrote in
message news:3b3d15f2$8$fuzhry$mr2...@va.news.verio.net...