Paul,
Since you mentioned the Unix shell vs JCL, why not use both? Here's a
simple example of using the Unix shell with a 'here document' to do
parameter substitution for an instream dataset using JCL parameters:
// SET NEWGDG=FOO.BAR.MYGDG
// SET GDGLIM=3
//*
// EXEC PGM=COZBATCH, <<FREE BPXBATCH replacement
// PARM='/NEWGDG=&NEWGDG GDGLIM=&GDGLIM'
//STDOUT DD DSN=&&TEMP,DISP=(NEW,PASS),
// DCB=(RECFM=FB,LRECL=80),SPACE=(CYL,(1,1))
//STDIN DD *
cat <<EOD
DEFINE GDG(NAME($NEWGDG) -
LIMIT($GDGLIM) -
NOEMPTY -
SCRATCH)
EOD
//*
//DEFGDG EXEC PGM=IDCAMS
//SYSIN DD DSN=&&TEMP,DISP=(OLD,DELETE)
//SYSPRINT DD SYSOUT=*
//
(And if you know the Unix shell, sed, awk, etc you can see how this could be
extended to do all sorts of file processing and symbol substitution in the
context of venerable JCL).
Of course, it would be much better if we could automatically import JCL
variables in the running program, and weren't limited by the pesky 100
character PARM= limit. But we have a workaround to the latter.... see
example #6 here: http://dovetail.com/docs/cozbatch/examples.html
Regards,
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
PS> You going to SHARE in Boston? We will be there on Tuesday doing "JZOS
meets Web 2.0"....
On Thu, Jun 24, 2010 at 8:48 PM, Paul Gilmartin <paulgboul...@aim.com>wrote:
> On Thu, 24 Jun 2010 13:37:50 -0500, Chris Mason wrote:
> >
> >You'll be wanting symbol substitution in the instream data next!
> >
> Me, too!
>
> When I do an SMP/E zone definition (assuming I'm still
> allowed to) I'd cherish being able to define several
> symbols with JCL SET statements, they apply them in
> JCL DD statements (as I can today), and likewise in
> instream IDCAMS SYSIN and SMP/E UCLIN data sets (which
> I can not.
>
> The suggestion of a horde of PARMLIB members selected
> by symbol values and concatenated falls short because of
> namespace constraints. And what happens if two symbols
> need to be substituted on the same line. UNIX directories
> with members selected by parameters would much relieve
> those constraints, as would a multitude of PS data sets.
> But from an ISV perspective, how do the parmeter libraries
> get set up and populated? I'd expect customers to see
> see either multiple PS data sets or multiple UNIX directories
> as unacceptable. I'd rather supply a JCLLIB INCLUDE
> member that the customer could tailor and which would
> perform all necessary substitutions in DD and SYSIN and
> UCLIN.
>
> >Oh! the answer to your question is that a procedure consists of job
> control
> >language statements and the card images between the //xxxxx DD * and /*
> >card images are not job control language statements.
> >
> Which is hardly an answer at all. On recognizing instream
> data, the reader shunts it aside to a data set and replaces
> it in the JCL with a reference to that data set. I see no
> reason that shouldn't work as well within a PROC as in open
> code.
>
> Symbol substitution would greatly complicate it; it
> would require substituting symbol values at the point
> of PROC call rather than at the point of PROC definition.
> Still a worthwhile facility. I'm accustomed to doing
> it in POSIX shell scripts; it would be equally useful
> in MVS JCL. Implementation: UNIX sh generally copies
> instream data to a file and then passes that file to
> the command executed. But it does the Right Thing
> (unlike JCL) and does the copy at the point of procedure
> call rather than at procedure definition, and substitutes
> symbols (optionally, of course) with their values at
> the point of call.
>
> -- gil
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
