n 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,
&g
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
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 Jul 2
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 GDGs
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
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
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
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
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
@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
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
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
tz3
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, if
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
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've done th
: 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 in later years 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
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; looks like
<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-web.
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 readiness
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,
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
eference?
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>>
>>
>> From: IBM Mainframe Discussion List on behalf
>> of ITschak Mugzach
>> Sent: Wednesday, July 11,
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
u 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-M
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 Jul 2018 19
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?
>
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
,DELETE)
Cliff McNeill
From: IBM Mainframe Discussion List on behalf of
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, July 11, 2018 2:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Overrides (was: REXX as JCL replacement)
O
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
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. Re
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
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
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),
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
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
tz
> 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 you say is true.
@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
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
as JCL replacement
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 som
-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 (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
it 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 lo
.
On Wed, Jul 11, 2018 at 11:03 AM, 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 ide
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
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 replacement
T
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
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
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
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
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
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
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
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
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 wrote:
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
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
. 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 10:46 PM, Hobart Sp
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 ...
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 it :-
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
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 current on VSE would
[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
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
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
: 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
just
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
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
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
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
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
@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 claims
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.
[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.
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..."
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
--
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
> To: IBM-MAIN
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,
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
> To: IBM-MAIN
.) 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 r
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.
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)
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Pau
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 asking:
"ENQ as
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 componen
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 that into your CL
On Thu, 5 Jul 2018 16:28:10 -0300, Clark Morris wrote:
>
>For batch processes how does the i series command language compare to
>JCL.
One typically uses CL to program ones batch jobs. And when I say 'program' that
is exactly what I mean. CL is a very complete programming language. It really
On Thu, 5 Jul 2018 06:40:39 -0700, Charles Mills wrote:
>Many moons ago we ported a product from z/OS to the AS/400 and were similarly
>impressed with the sorts of things you mention. The OS was solid as a rock.
Hear, hear !
>
>There is a major learning curve
Having gone down that path, I
1 - 100 of 135 matches
Mail list logo
