ussion List on behalf
> of Savor, Thomas (Alpharetta)
> Sent: Wednesday, March 20, 2019 1:42 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL
> replacement
>
> Many years ago when Converting a DDA system from Burroughs to IBM,
&
From: IBM Mainframe Discussion List on behalf of
Savor, Thomas (Alpharetta)
Sent: Wednesday, March 20, 2019 1:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL
replacement
Many years ago when Converting a DDA
Many years ago when Converting a DDA system from Burroughs to IBM, Burroughs
packed fields had the annoying habit of putting the sign at the beginning of
the fieldinstead of the end of the field like IBM.
Made for pages and pages of "Move with Offsets" in the Assembler
programsCobol didn
metz3
From: IBM Mainframe Discussion List on behalf of Tom
Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, July 10, 2018 11:58 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL
replacement
On Mon, 9
Ah, OK. We didn't have a tape/disk manager.
From: IBM Mainframe Discussion List on behalf of
Tony Thigpen
Sent: Thursday, July 12, 2018 8:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX as JCL replacement
All the main disk and tape managers have
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 ne
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
O
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. Exa
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
--
I was not involved, but I will reach out to the ones that were.
Tony Thigpen
Clem Clarke wrote on 07/13/2018 05:07 AM:
Perhaps Tony you could say why Jol was rejected?
Thanks,
Clem
Tony Thigpen wrote:
Using pipelines could require a lot of programming changes.
Historically, programs tend to
Perhaps Tony you could say why Jol was rejected?
Thanks,
Clem
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.
I like the
Oh! Didn't know that. I moved to the East Coast of Australia, and lost
contact...
David Crayford 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
Tony Thigpen - very observant.
Yes, there is an optional back-end database for Data Set Information.
This was originally added to Jol so that the people in the department
looking after the Data Sets on the machine could be separate from the
people writing the code to actually execute the prog
@LISTSERV.UA.EDU
Subject: Re: REXX as JCL replacement
Restarts with GDGs is one thing z/VSE is much better at. Once a GDG is
created in a step, it becomes the current GDG for all following steps.
So, following steps don't need to reference +1, then require a change
during a restart.
It part o
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 (and
Since when does z/VSE have GDGs??
From: IBM Mainframe Discussion List on behalf of
Tony Thigpen
Sent: Wednesday, July 11, 2018 1:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX as JCL replacement
Restarts with GDGs is one thing z/VSE is much better at
/~smetz3
From: IBM Mainframe Discussion List on behalf of
Hobart Spitz
Sent: Monday, July 9, 2018 3:20 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: REXX as JCL replacement
Steve, thanks for the kind words.
One afterthought that might improve the use of the TSO PROC
To: IBM-MAIN@listserv.ua.edu
Subject: Re: REXX as JCL replacement
On Mon, 9 Jul 2018 15:20:07 -0400, Hobart Spitz wrote:
>Steve, thanks for the kind words.
>
>One afterthought that might improve the use of the TSO PROC, if one is so
>inclined. Use // EXEC TSO,CMD=REXXTRY , Put
day, July 9, 2018 8:56 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: REXX as JCL replacement
On Mon, 9 Jul 2018 16:45:00 -0700, Charles Mills wrote:
>I wrote a product that as part of its processing generated JCL. (It was a side
>chore; it was not a "JCL-generator.") ...
>
I'
3353
Sent: Thursday, July 12, 2018 12:38 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: REXX as JCL replacement
It was explained to me in my brief contact with the language back in the early
1970's that WFL was essentially a dialect of Algol 60 with no I/IO facilities.
What it grew to become i
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 m
a thorough reading.
Thanks for the link Tom.
Peter
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Seymour J Metz
Sent: Thursday, July 12, 2018 12:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX as JCL replacement
Thanks; lo
chant <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, July 11, 2018 5:30 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: REXX as JCL replacement
On Wed, 11 Jul 2018 17:29:28 +, Seymour J Metz wrote:
>Do you have a link to the WFL reference?
I posted it yesterday.
https://secure
ehalf of
ITschak Mugzach
Sent: Wednesday, July 11, 2018 4:45 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: REXX as JCL replacement
BTW, I wrote a rexx interpreter of JCL a year ago. ITs so easy because JCL
has a name token format, almost nothing is positional. The aim was
verifying security readine
On Wed, Jul 11, 2018, 14:01 Hobart Spitz wrote:
> Sorry John. I know how businesses work. My comment was rude, sarcastic,
> and uncalled for. I should not have sent it.
>
Cheerfully accepted. Compared to what a person said to me on a Per language
"newbies" forum, your reply was, at most, chid
On 7/11/2018 12:09 PM, Tom Marchant wrote:
An example of an incremental improvement is IF/THEN/ELSE/ENDIF.
I remember that - right about the time I finally understood how COND=
worked. Of course I really didn't.
--
For IBM
The syntax using stepname (not procstep name) is used because there is no
nested procedure in that refer back. By that I mean, the reference is not to a
DD within a proc invoked by the procedure. That is how I've always viewed it.
I reread the JCL manual concerning backward references and it
On Wed, 11 Jul 2018 22:45:38 +0200, ITschak Mugzach wrote:
>BTW, I wrote a rexx interpreter of JCL a year ago. ITs so easy because JCL
>has a name token format, almost nothing is positional.
>
Parameters on JOB?
Parameters on EXEC?
Subparameters of DCB, LABEL, ...?
(Well, you said "almost".)
> .
On Wed, 11 Jul 2018 17:29:28 +, Seymour J Metz wrote:
>Do you have a link to the WFL reference?
I posted it yesterday.
https://public.support.unisys.com/aseries/docs/ClearPath-MCP-18.0/86001047-516
--
Tom Marchant
--
For I
eference?
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>>
>>
>> From: IBM Mainframe Discussion List on behalf
>> of ITschak Mugzach
>> Sent: Wednesday, July 11, 20
TSERV.UA.EDU
> Date: 07/11/2018 04:39 PM
> Subject: Re: REXX as JCL replacement
> Sent by: "IBM Mainframe Discussion List"
>
> Restarts with GDGs is one thing z/VSE is much better at. Once a GDG is
> created in a step, it becomes the current GDG for all following st
ave a link to the WFL reference?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> From: IBM Mainframe Discussion List on behalf
> of ITschak Mugzach
> Sent: Wednesday, July 11, 2018 6:20 AM
> To: IBM-M
x27;s were first introduced.
Peter
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Wednesday, July 11, 2018 3:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Overrides (was: REXX as JCL replacement)
On Wed, 11 J
On Wed, 11 Jul 2018 19:30:16 +, Clifford McNeill wrote:
>The proc author probably wouldn't do in that manner. Look at excerpt below,
>notice how LKED SYSLIN is referencing a dsn from a previous step?
>
>SYS1.PROCLIB(IBMZ
Restarts with GDGs is one thing z/VSE is much better at. Once a GDG is
created in a step, it becomes the current GDG for all following steps.
So, following steps don't need to reference +1, then require a change
during a restart.
It part of the difference that z/OS reads the whole job in then
Sent: Wednesday, July 11, 2018 2:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Overrides (was: REXX as JCL replacement)
On Wed, 11 Jul 2018 10:35:08 -0700, Lizette Koehler wrote:
>I would include the caveat
>
>Even though it is available, do not use Nested procs. Trying to override a
>proc wi
On Wed, 11 Jul 2018 14:09:16 -0500, Tom Marchant wrote:
>>
>>>I don't like JCL, but I don't see any way forward other than incremental
>>>improvements.
>>>
>>Business case for those? And trimming the whiskers from JCL would
>>create compatibility problems for users who have come to depend on
>>th
v.ua.edu>
Sent: Wednesday, July 11, 2018 2:51 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: REXX as JCL replacement
On Wed, 11 Jul 2018 18:09:21 +, Seymour J Metz wrote:
>You keep missing the point that REXX does not currently provide the
>serialization
>that is available through JCL.
On Wed, 11 Jul 2018 10:35:08 -0700, Lizette Koehler wrote:
>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.
>
I can't decide whether the author of the original RFE overlooked a requi
On Wed, 11 Jul 2018 13:51:05 -0500, Paul Gilmartin wrote:
>On Wed, 11 Jul 2018 18:09:21 +, Seymour J Metz wrote:
>
>>I don't like JCL, but I don't see any way forward other than incremental
>>improvements.
>>
>Business case for those? And trimming the whiskers from JCL would
>create compatib
Sorry John. I know how businesses work. My comment was rude, sarcastic,
and uncalled for. I should not have sent it.
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
On Wed, 11 Jul 2018 18:09:21 +, Seymour J Metz 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.
>
??CLM??
>That's why I sugge
On Wed, Jul 11, 2018 at 1:38 PM Hobart Spitz wrote:
> John; So the production schedules set policy in your shop. Do they pay
> the bills too?
>
Well, they run the jobs which keep the company running which pays my
salary. But if you want who, at least in the past, sets policy -- it was
the end
(Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> From: IBM Mainframe Discussion List on behalf
> of Hobart Spitz
> Sent: Wednesday, July 11, 2018 1:30 PM
> To: IBM-MAIN@listserv.ua.edu
> Subject: Re: REXX as JCL replacement
>
> Skip;
>
> What y
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 t
day, 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 sto
On Wed, Jul 11, 2018 at 12:01 PM Jesse 1 Robinson
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 JC
ehalf 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 r
Do you have a link to the WFL reference?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
ITschak Mugzach
Sent: Wednesday, July 11, 2018 6:20 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: REXX as
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 replace
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
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 sequentia
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 wh
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 th
#x27;s lots of room for improvement.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Hobart Spitz
Sent: Wednesday, July 11, 2018 8:37 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: REXX as JCL repl
On Wed, Jul 11, 2018 at 6:40 AM, David Crayford wrote:
> 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 pr
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 softw
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 w
Speaking of replacing JCL, how about unisys WFL? It's a programming
language dedicated to job flows. BTW, I am happy with jcl...
ITschak
On Wed, Jul 11, 2018 at 12:09 PM Tony Thigpen wrote:
> So where does JOL get all the other informatoin for the DD card? Is
> there some back-end database that
So where does JOL get all the other informatoin for the DD card? Is
there some back-end database that has information for all the files that
may be used?
Tony Thigpen
Clem Clarke wrote on 07/10/2018 08:33 PM:
Below is an example of Jol, and the equivalent JCL.
Clem
Simplified Jol Scripting
Below is an example of Jol, and the equivalent JCL.
Clem
Simplified Jol Scripting Language for Z/OS, TSO, Linux and Windows
Payroll: Job class C 1000 k;
Exec Validate Input.Trans, Trans.Action(+1); /* Validate Transations */
if Validate=0
then do;
Sort transaction(+1) to Sorted.Trans.Action
Jol has a comprehensive menu system too.
Or it can be used with a PL/I type English like script.
For example,
Testjob: job;
Print Sys1.Maclib(call);
Clem
Jantje. wrote:
On Thu, 5 Jul 2018 15:08:01 -0500, Dana Mitchell wrote:
Most everything is menu driven,
Indeed it is, but hitti
Paul Gilmartin wrote:
On Thu, 5 Jul 2018 14:23:35 -0400, Hobart Spitz wrote:
I think a more encompassing approach would be for JOL to be a function,
command or environment which could be invoked from REXX.
JOL could be invoked from REXX. Or JCL.
When the JOL *compiler* is invoked from TSO tho
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.
However, there's an interesting IBM lab in Perth that has some excellent
people. Not many people know about it.
I worked there for a fe
frame Discussion List on behalf of Tom
Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, July 10, 2018 11:58 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL
replacement
On Mon, 9 Jul 2018 16:41:40 -0300, Clark Morris w
On Tue, 10 Jul 2018 10:28:05 -0500, John McKown wrote:
>I'm having a discussion on another,
>gaming, forum where one person insists that I simply can't be doing what I
>have been for about a month. Because I'm using a tool which "can't do
>that".
When my daughter was in high school she wrote a v
On Mon, 9 Jul 2018 16:41:40 -0300, Clark Morris wrote:
>How would the WFM (Work Flow Manager IIRC) for the Burroughs B500 and
>successor compare with IBM z/OS JCL and with VSE JCL. How does z/OS
>JCL compare with VSE JCL? My memories of DOS360 JCL probably are
>irrelevant.
I worked on a Burroug
with REXX.
Roger W. Suhr
suhr...@gmail.com
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
David Crayford
Sent: Monday, July 9, 2018 21:32
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX as JCL replacement
On 10/07/2018 7:15 AM, Andrew Rowley wrote:
> On 9/07/2018
On Tue, Jul 10, 2018 at 10:19 AM Seymour J Metz wrote:
> It wouldn't help; lots of people don't know what they platform that they
> are running on can do, much less other platforms. If I had $1 for every
> time somebody told me that, e.g., ISPF, couldn't do that I'd been doing for
> decades ...
>
rom: IBM Mainframe Discussion List on behalf of
Ward Able, Grant
Sent: Tuesday, July 10, 2018 5:12 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: REXX as JCL replacement
Seymour, I have to interject here and state that I like JCL. There - it is out
in the open and I feel much better for having said
Like I said, I was using cards when I last worked on VSE, so it's been a little
while... ;)
I'll be curious to hear whats changed too
Dana
On Tue, 10 Jul 2018 09:15:57 -0400, Tony Thigpen wrote:
>I wish those of you not current on VSE would remember that we have had
>just as many years to cha
ason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Tony Thigpen
Sent: Tuesday, July 10, 2018 9:15 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL
replacement
I wish those of you not
[Default] On 10 Jul 2018 06:16:08 -0700, in bit.listserv.ibm-main
t...@vse2pdf.com (Tony Thigpen) wrote:
>I wish those of you not current on VSE would remember that we have had
>just as many years to change things as z/OS has. Oh, wait, we have
>longer. DOS came out before what ever MVS was call
W dniu 2018-07-10 o 15:15, Tony Thigpen pisze:
I wish those of you not current on VSE would remember that we have had
just as many years to change things as z/OS has. Oh, wait, we have
longer. DOS came out before what ever MVS was called back then.
z/VSE has a lot of things in the JCL that z/O
On Tue, Jul 10, 2018 at 8:16 AM Tony Thigpen wrote:
> I wish those of you not current on VSE would remember that we have had
> just as many years to change things as z/OS has. Oh, wait, we have
> longer. DOS came out before what ever MVS was called back then.
>
OS/360 -- either MFT or MVT.
I wish those of you not current on VSE would remember that we have had
just as many years to change things as z/OS has. Oh, wait, we have
longer. DOS came out before what ever MVS was called back then.
z/VSE has a lot of things in the JCL that z/OS has no equal to. I work
both areas and there
... And I may add that if VSE JCL was so good, it wouldn't have so many
private extensions (and I've seem some of them).
ITschak
On Tue, Jul 10, 2018 at 2:37 PM Dana Mitchell wrote:
> My memories of VSE JCL are dated, and quite possbily incorrect with
> current VSE, but I recall that I felt it
My memories of VSE JCL are dated, and quite possbily incorrect with current
VSE, but I recall that I felt it was more complicated that MVS jcl. It had
more types of statements (although fewer parms per type), JOB, * $$ JOB,
UPSI, OPTION, LIBDEF, PAUSE, and EXEC statements. To describe a d
: 09 July 2018 16:10
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX as JCL replacement
ATTENTION! This email originated outside of DTCC; exercise caution.
1. I don't recall anybody on IBM-MAIN claims that JCL is good.
2. Creative solutions are good if they solve the actual problem, not
On 10/07/2018 7:15 AM, Andrew Rowley wrote:
On 9/07/2018 10:46 PM, Hobart Spitz wrote:
Basically, JCL is so far from real a programming language, that I can't
describe it.
That's because JCL isn't a programming language. There are plenty of
other languages that also suck as programming langua
On Mon, 9 Jul 2018 16:45:00 -0700, Charles Mills wrote:
>I wrote a product that as part of its processing generated JCL. (It was a side
>chore; it was not a "JCL-generator.") ...
>
I've done that a lot. I like to keep JCL embedded in POSIX shell scripts as
here-documents.
o Not Rexx, first bec
Ed Jaffe posted a video... it seems he worked some magic on it so that it's
only an excerpt from a longer presentation. It runs about 5 minutes, and
it's well worth that. Frederick P. Brooks had many talents, one of which
is he's an engaging and funny speaker.
The upshot (for our purposes) of hi
ssion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Andrew Rowley
Sent: Monday, July 9, 2018 4:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX as JCL replacement
On 9/07/2018 10:46 PM, Hobart Spitz wrote:
>
> Basically, JCL is so far from real a programming language, that I can
On 9/07/2018 10:46 PM, Hobart Spitz wrote:
Basically, JCL is so far from real a programming language, that I can't
describe it.
That's because JCL isn't a programming language. There are plenty of
other languages that also suck as programming languages e.g. HTML, XML,
JSON, but that's not wha
-MAIN@LISTSERV.UA.EDU
Subject: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement
[Default] On 9 Jul 2018 11:14:20 -0700, in bit.listserv.ibm-main
edja...@phoenixsoftware.com (Ed Jaffe) wrote:
>On 7/9/2018 8:09 AM, Seymour J Metz wrote:
>> 1. I don't recall anybody on IBM-MAIN
On Mon, 9 Jul 2018 15:20:07 -0400, Hobart Spitz wrote:
>Steve, thanks for the kind words.
>
>One afterthought that might improve the use of the TSO PROC, if one is so
>inclined. Use // EXEC TSO,CMD=REXXTRY , Put REXXTRY into one of the
>SYSEXEC/SYSPROC libraries, if it's not already there. It
[Default] On 9 Jul 2018 11:14:20 -0700, in bit.listserv.ibm-main
edja...@phoenixsoftware.com (Ed Jaffe) wrote:
>On 7/9/2018 8:09 AM, Seymour J Metz wrote:
>> 1. I don't recall anybody on IBM-MAIN claims that JCL is good.
>
>Even Fred Brooks (who led the IBM team that invented JCL) calls it "the
Steve, thanks for the kind words.
One afterthought that might improve the use of the TSO PROC, if one is so
inclined. Use // EXEC TSO,CMD=REXXTRY , Put REXXTRY into one of the
SYSEXEC/SYSPROC libraries, if it's not already there. It gives access to
most of REXX to the SYSTSPRT records. REXXT
On 7/9/2018 8:09 AM, Seymour J Metz wrote:
1. I don't recall anybody on IBM-MAIN claims that JCL is good.
Even Fred Brooks (who led the IBM team that invented JCL) calls it "the
worst programming language ever designed anywhere by anybody for any
purpose..."
https://youtu.be/8c0_Lzb1CJw?t
I'd like to point out that Hobart Spitz's long post is a great overview of
the practical and useful way that at least some JCL could be replaced with
REXX. The details can be nit-picked eternally (and no doubt will be).
sas
--
F
nd
accesses, must be SHaRed. What am I missing?
Thanks.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> From: IBM Mainframe Discussion List on behalf
> of Hobart Spitz
> Sent: Monday, July 9, 2018 8:4
On Mon, Jul 9, 2018 at 11:12 AM Hobart Spitz wrote:
> On Mon, Jul 9, 2018 at 11:09 AM, Seymour J Metz wrote:
>
> > 1. I don't recall anybody on IBM-MAIN claims that JCL is good.
> >
> There were such statements as "I like JCL", or similar.
>
And there are people who like Limburger cheese, too
cesses, must be SHaRed. What am I missing?
Thanks.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> From: IBM Mainframe Discussion List on behalf
> of Hobart Spitz
> Sent: Monday, July 9, 2018 8:46 AM
our J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Hobart Spitz
Sent: Monday, July 9, 2018 8:46 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: REXX as JCL replacement
Ward wrote:
>What are the problems (perceived or re
On Mon, 9 Jul 2018 08:46:56 -0400, Hobart Spitz wrote:
>
>I think that it's important to first understand the characteristics on
>which many people base their thinking that JCL is good and may never go
>away. The point is important, and the basis is a valid concern. The
>conclusion is wrong. All
en theory and practice. In practice,
> there is.
>
> There is no such thing as the Cloud. It is just somebody else’s computer.
>
> If you don't have time to do it right, when will you have the time to do
> it over? - John Wooden
>
>
> DTCC Internal (Green)
&g
4:29 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: REXX as JCL replacement
I have not really thought it through but I just cannot picture how building
some combination of Rexx or whatever + assembler one could not do 'n'
simultaneous ENQs. The facilities are there in MVS for the a
metz3
From: IBM Mainframe Discussion List on behalf of
Charles Mills
Sent: Thursday, July 5, 2018 6:35 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: REXX as JCL replacement
Right. And I don't believe "JCL" does. I think think the scheduling c
On Thu, 5 Jul 2018 15:08:01 -0500, Dana Mitchell wrote:
>Most everything is menu driven,
Indeed it is, but hitting PF14 on that menu will show you the equivalent CL
command with all the options you just filled in in the right place and with the
correct syntax. Just cut&paste that into your CL
1 - 100 of 138 matches
Mail list logo