John;  So the production schedules set policy in your shop.  Do they pay
the bills too?

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 2:09 PM, Seymour J Metz <sme...@gmu.edu> wrote:

> You keep missing the point that REXX does not currently provide the
> serialization that is available through JCL. Rewriting the job as a REXX
> script that does not do the necessary serialization is a CLM. That's why I
> suggested a parallel allocation facility usable from REXX.
>
> I don't like JCL, but I don't see any way forward other than incremental
> improvements.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> ________________________________________
> From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf
> of Hobart Spitz <orexx...@gmail.com>
> Sent: Wednesday, July 11, 2018 1:30 PM
> 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://secure-web.cisco.com/1vPv31WBXBT1zFq5Jok_
> TQrDIW17DDLt3jbvRME3ZinOiLdfN7IJ9HM9i0r-y969-qSZy8zN__
> 1EC982Nn1N1MNPVzPnnotq686mQo7NcBidOmguumNuGzCKnQj3_
> wjdNOsymf5WluMaEcQxFcYWWObgQahYyErJAZX8OuB2tGU50qKbGDIxtAMT7
> 4iWjCC15wrGFlMzwvpNLTkVt9VfMa1dZ1zG-jItf3aT_1Ki40dTVC-
> 8RTypOjtuDtNwPE1cGDXpqiNfCZ2nGwVYeiTfw-sK5KpbqpXAw28GrkRBzxse01OsmrZY
> QczcQzNCqanz3xSqYZ1dEqoKnSSYfUDqGLH5XWvpHiHt2AskNPZCZ-
> jVGhgYnuAQFJkSQu-REVCUi/http%3A%2F%2Fvm.marist.edu%2F%7Epipeline%2F
> >
> > The author's edition, the primary source of PIPElines information, can be
> > found at.
> >
> > http://secure-web.cisco.com/1DkJEaI3yU5IZP37yYVRY2GReQj7wR
> 1FZPTlPwK3qOcYqAfweqMv0_zybvyhmIgS0XluyeavRY5xC4c_
> Ccn3IlXPYzsQD6UV9ukzp6z1pZwfvfDlwVxbfUJ_DUmp1LasHuRZmMyQ4ry-_YSz_
> 1TXlfs4P1xFb9jSU8KFnBcZrpkrXnIQgR_VMdQBvG_YmofM8LoTiRzDVVBIiBoObEbUg1kwo
> pu5GMy1qJ4JZUcZY9H_m6Luth7RBt8TIeBJuXOWR3UcyCRlMl
> nvkxmKPMl2GMU0NaGyoOnRxkBBivWx9Fvk4vxkmZA3hI9Dy7O_CN0V9rl1ssWoJvA_
> 8CcKN9r78DnLq0lwrcSPjYJZ4kP0VNqs5J6CXjzLe5Mj6QSF4gGtT/http%
> 3A%2F%2Fwww-01.ibm.com%2Fsupport%2Fdocview.wss%3Fuid%3Dpub1sl26001805
> >
> > 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
>

----------------------------------------------------------------------
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