I would include the caveat

Even though it is available, do not use Nested procs.  Trying to override a 
proc within a proc within a proc ..   rarely succeeds.

Lizette



> -----Original Message-----
> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of
> Hobart Spitz
> Sent: Wednesday, July 11, 2018 10:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: REXX as JCL replacement
> 
> Skip;
> 
> What you say is true.  Massive replacement would not be justified.  No one is
> advocating such an effort.
> 
> What needs to happen is for people to stop writing new JCL (or copying old
> JCL, especially the bad stuff) and work as if it were the 21st century.
> 
> In addition to not writing new JCL, there are some prime replacement
> candidates to consider now:
> 
>    - PROCs are executed frequently.  The improvements, whether functional
>    or performance, would be multiplied across all JOBs that EXECute those
>    PROCs.
>    -
>    - PROCs that only use utilities and/or batch TSO, combining all into one
>    step.
>    - Replacing frequently executed IEFBR14s that sometimes create a dataset
>    just to delete it, or that delete perfectly good dataset.  Are all those
>    ENQs, RESERVEs, catalog searches and updates, and VTOC searches and
> updates
>    really worth it just because DISP=MOD can't change DCB info?
>    - JOBs with complex parameter or restart requirements.
>    - JOBs that run frequently.
>    - JOBs that need special serialization.  Invoke the program(s) in a REXX
>    loop.  Serialization problems gone.
>    - Applications that do updates primarily in DB2 and/or PDSEs.
>    - Applications that need more generalized automation.  Drop the
>    expensive third-party software.  You play by your rules, not someone
> else's.
>    - Any process that has complex or hard to maintain JCL.
> 
> There are more.
> 
> Once you understand the benefits, to vendors and customers, the choice is
> clear.
> 
> OREXXMan
> JCL is the buggy whip of 21st century computing.  Stabilize it.
> Put Pipelines in the z/OS base.  Would you rather process data one character
> at a time (Unix/C style), or one record at a time?
> IBM has been looking for an HLL for program products; REXX is that language.
> 
> On Wed, Jul 11, 2018 at 1:00 PM, Jesse 1 Robinson <jesse1.robin...@sce.com>
> wrote:
> 
> > This thread is entertaining but largely cherry-pie-in-the-sky. While
> > it might be a nice exercise for sysprogs and architects, what's
> > missing so far is a compelling business case to justify the pain and
> > agony of actually replacing JCL in a real world environment. For a
> > mature shop with thousands of jobs to manage--most of which work very
> > well most of the time--it would be a very hard sell to justify
> > resources to build a replacement that would mostly work better most of the
> time.
> >
> > I'm reminded of the old saw about teaching a dog to walk on its hind legs.
> > What's compelling is not that the dog does it well but merely that she
> > can walk that way at all. Worth maybe admission to a vaudeville show
> > but not a reason to turn your life upside down.
> > .
> > .
> > J.O.Skip Robinson
> > Southern California Edison Company
> > Electric Dragon Team Paddler
> > SHARE MVS Program Co-Manager
> > 323-715-0595 Mobile
> > 626-543-6132 Office ⇐=== NEW
> > robin...@sce.com
> >
> >
> > -----Original Message-----
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Hobart Spitz
> > Sent: Wednesday, July 11, 2018 9:42 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: (External):Re: REXX as JCL replacement
> >
> > Gil wrote:
> > >SORT is quasi-batch:
> > A REXX filter using ADDPIPE, or a "sipping" filter using CALLPIPE, can
> > run
> > SORT(s) to completion completely independently of the main pipe, to
> > name just two possibilities.  The terminology in the PIPElines
> > documentation is "delaying records".  Most built-in filters don't
> > delay records, others might delay some records some of the time, and
> > others, like SORT delay, of necessity, all records.  Any filter that
> > has to hold on to a record and "think about it" before producing the
> > corresponding result is said to "delay the record".
> >
> > Any sequence of filters, each of which don't delay the record, when
> > combined in a single stream, will not delay the record.  So much of
> > the time, you don't have or don't care about record delay.
> >
> > Delaying records doesn't into play until you get into non-trivial
> > multiple-stream PIPElines, where you have split a data stream into two
> > and then later combine them.  In order for the right records to arrive
> > at the desired time at the joining point, you may need to take record
> > delay into account.  This is something that is impossible in UNIX (at
> > this time), because UNIX piping data flow is not deterministic.
> >
> > Beginning pipers don't usually run into the issue.  For one, there is
> > so much you can do with REXX and single stream PIPElines.  For
> > another, multi-stream PIPElines require a small additional level of
> > knowledge concerning functionality and syntax.  Melinda Varian has
> > written some excellent papers and talks on PIPElines.  She was a long time
> advocate and
> > champion of PIPElines, especially under z/VM and CMS.   You can find her
> > papers and more at
> >
> > http://vm.marist.edu/~pipeline/
> >
> > The author's edition, the primary source of PIPElines information, can
> > be found at.
> >
> > http://www-01.ibm.com/support/docview.wss?uid=pub1sl26001805
> >
> > You need only read the first few chapters before you will start
> > drooling to have the product.  No joke.  You'll begin to realize how
> > much your productivity has been hampered by not having better tools at your
> disposal.
> >
> > I capitalize PIPElines this way because, apparently, there is a UNIX
> > pipe command which has no connection or similarity to the TSO/CMS product.
> >
> >
> > OREXXMan
> > JCL is the buggy whip of 21st century computing.  Stabilize it.
> > Put Pipelines in the z/OS base.  Would you rather process data one
> > character at a time (Unix/C style), or one record at a time?
> > IBM has been looking for an HLL for program products; REXX is that
> > language.
> >
> > On Wed, Jul 11, 2018 at 11:54 AM, Paul Gilmartin <
> > 0000000433f07816-dmarc- requ...@listserv.ua.edu> wrote:
> >
> > > On Wed, 11 Jul 2018 11:03:05 -0400, Tony Thigpen wrote:
> > >
> > > >Using pipelines could require a lot of programming changes.
> > > >Historically, programs tend to be designed to process batches, not
> > > records.
> > > >
> > > >Most shops will not have the bodies to do the changes needed.
> > > >
> > > Many programs process data sequentially and are well suited to using
> > > pipes, which merely bypass temporary files and require no other changes.
> > >
> > > In ancient, main-storage-constrained environments pipes might
> > > actually degrade performance: having multiple programs co-resident
> > > caused paging I/O that overwhelmed any benefit of less temp file I/O.
> > >
> > > SORT is (too) often given as an example of a pipe stage.  It can be
> > > inappropriate because SORT is quasi-batch:  SORT can not write the
> > > first record to SORTOUT until it reads the last record from SORTIN.
> > >
> > > >I like the idea of REXX as a JCL replacement. It can provide a lot
> > > >better logic. I don't know that it will make many inroads due to
> > > >lack of man-power, but it can be a method to the future.
> > > >
> > > >One of our staff looked seriously at JOL and rejected it.
> > >
> > > -- gil
> >
> >
> > ----------------------------------------------------------------------
> > For IBM-MAIN subscribe / signoff / archive access instructions, send
> > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> 
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to