It may be a long, slow process, generally and/or at some sites, but if
enough people do it, JCL will become the exception. IBM and site
management will get it, and additional needed tools/solutions or something
even better will be made available. Eventually.
Try it. Use what works. Refine what doesn't.
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:03 AM, Tony Thigpen <t...@vse2pdf.com> 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.
>
> 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.
>
> Tony Thigpen
>
> Hobart Spitz wrote on 07/11/2018 08:37 AM:
>
>> The JOL effort is commendable, but replacing JCL is about much more than a
>> nicer syntax or easy movement between foreground and background.
>>
>> At the risk of repetition, other reasons are (1) to eliminate the
>> separation between scripting code and application code and (2) to
>> interface
>> with other software/data (files, DB2, ISPF, etc.).
>>
>> Resistance to replacing JCL comes from the fact that "everybody knows JCL"
>> (which they don't really). Everybody (in the target audience) knows REXX,
>> if not directly, then because REXX has many well-know features of other
>> languages. JCL resembles only mainframe assembler.
>>
>> Add in PIPElines and you get a productivity and performance improvements
>> unlike any other option available. Charles's example in REXX and
>> PIPElines
>> might look like this.
>>
>> 1. "pipe (end ?) ? < trans | v: validate | g: gate",
>> 2. "? v: sort 10.10 | g:| u: update | >" GDG("payroll.master(+1)")",
>> 3. "? <" GDG("payroll.master(0)") | u:"
>> 4.
>> 5. if RC = 0 then
>> 6. "submit job2"
>> 7. else
>> 8. "delete" GDG("payroll.master(0)")
>>
>>
>> I tried to stay true to Charles's example. If you can to skip invalid
>> transactions, but still process valid ones (a reasonable approach), you
>> can
>> eliminate the GATE and combine the first two streams.
>>
>> GDG() is a function that I've previously written.
>>
>> Note that zero intermediate files are needed, saving those I/O operations.
>>
>> I haven't read the details of JOL, so I might be missing something. I'm
>> happy to be educated.
>>
>>
>> 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 6:40 AM, David Crayford <dcrayf...@gmail.com>
>> wrote:
>>
>> On 11/07/2018 7:19 AM, Clem Clarke wrote:
>>>
>>> Don't know about that! I always think that IBM has some of the best
>>>> people and concepts. Pity IBM didn't push PL/I instead od allowing C to
>>>> rule the world.
>>>>
>>>>
>>>> They did, but something that's free will always be more attractive.
>>> Multics was originally written in PL/I but the UNIX devs didn't think it
>>> was suitable for operating systems.
>>>
>>> However, there's an interesting IBM lab in Perth that has some excellent
>>>
>>>> people. Not many people know about it.
>>>>
>>>>
>>> Not any more! They all got the push when IBM recently cut their
>>> workforce.
>>> A few of them moved to HCL with the PD products. The rest of them are
>>> looking for work.
>>>
>>>
>>> ----------------------------------------------------------------------
>>> 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
