JCL can submit further jobs to the internal reader to get around the 255
steps limit. Loops can be implemented in JCL by submitting a job that
then resubmits itself n times, based on a counter passed in a dataset
(and decremented at each resubmission) and on a same LPAR. A jobstep
that creates a
On 2018-07-13 01:29, CM Poncelet wrote:
What 'problem' with JCL is fixed by replacing it with REXX?
REXX doesn't have a limit of 255 steps in a job, and that limit may be reached
when doing regression tests. It also allows loops. Example I have is too long to
post here (probably).
Robert
No sane person would seriously advocate the "demise" of JCL. All the
slings & arrows it's suffered here lately are just the motivation for
trying alternatives; or for some proposed enhancements. The continued
existence and use of JCL (moot anyway) is no impediment to the alternatives.
sas
On Sat, 14 Jul 2018 09:30:37 +, Robert Prins wrote:
>On 2018-07-13 01:29, CM Poncelet wrote:
> > What 'problem' with JCL is fixed by replacing it with REXX?
>
>REXX doesn't have a limit of 255 steps in a job, and that limit may be reached
>when doing regression tests. It also allows loops.
On 2018-07-13 01:29, CM Poncelet wrote:
> What 'problem' with JCL is fixed by replacing it with REXX?
REXX doesn't have a limit of 255 steps in a job, and that limit may be reached
when doing regression tests. It also allows loops. Example I have is too long to
post here (probably).
Robert
Yes, runnning in programs batch is always more efficient than in TSO -
just as invoking assembler programs from REXX is more efficient than
invoking REXX from assembler (via "ISPLINK" is it?)
If JCL is 'strange', consider then native SMP/E. I never had a problem
with JCL or with native SMP/E
My information may be out of date... but as I remember someone, possibly
Barry Merrill, did the research and found that running a program under TSO
cost about three times what it cost in batch. And REXX's are usually run
in a TSO environment, even when run as TSO-Batch.
Has this changed?
Perhaps
