Re: Why is JCL so bad?
john gilmore
" . . . Its objectives make JCL more like a macro processor than a programming language, but it failed to incorporate much of the current assembler's macro processing capability, and neither JCL nor HLASM conditional assembly has graceful branching nor [sic] clean iteration."
Statements of this sort are and should be constitutionally protected, but this one is without much redeeming technical merit.
JCL has been criticized by those who have not mastered it since the time of OS PCP. Its syntax, borrowed from that of then current assemblers, is said to be "difficult to learn", for reasons that I have never understood; but it is not indefensible. In particular, it is more powerful than the alternatives to it that I have seen.
He begins here by attempting to distinguish a macro processor and a programming language, implying it would seem that a macro processor is not a programming language; but he then proceeds immediately to criticize, a little ungrammatically but unambiguously enough, both JCL and the HLASM as lacking two of the important attributes of programming languages, viz., "graceful branching" and "clean iteration". Now grace and cleanliness are in the eyes of their beholders. Consider
|&baid setc '&macname'.'__boolean_array__'
| gblb &(&baid)(1)
|&nbae seta n'&(&baid)
|&i seta 0
|.reiz_loop anop
|&i seta &i+1
|&eoa setb (&i gt &nbae)
| aif (&eola).reiz_lend
|&(&baid)(&i) setb 0
| ago .reiz_loop
|.reiz_lend anop
This HLASM macro-language statement group resets the elements of an array of created global binary/boolean set symbols to their default value, boolean 0. Someone unfamiliar with the HLASM macro language would find it unintelligible; and there is a familiar, now tedious perspective from which it is judged long-winded and/or detail-ridden; but there is nothing unclean about it.
Examples of this sort could be proliferated ad infinitum et nauseam, but they would not persuade Mr. Gilmartin to my views, and that is as well.
What distresses me about these views is not their substance, with which I expect usually to disagree. It is his perspective. He judges that his needs, which I often judge to be whims, should be satisfiable all but immediately, without much programming, by a tool that he is using and that the machinery employed to do so should conform to his particular, municipal notions of cleanliness and grace.
These requirements ensure that he will always be dissatisfied with every tool he uses that was designed and implemented by others. We are all creatures of our own very different experiences.
John Gilmore Ashland, MA 01721-1817 USA
_________________________________________________________________
Hotmail: Trusted email with powerful SPAM protection.
http://clk.atdmt.com/GBL/go/177141665/direct/01/
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Charles Mills
Charles
Ted MacNEIL
I've been using JCL since February 1981.
I started in this business as a JCL jockey in Production Support for a Canadian Railway Company that was building a new data centre in Toronto.
While we were moving from Montreal to Toronto, we had a lot of spare time in the new Control Room.
So, I spent a lot of time learning JCL, utilities, CLISTs, and ISPF (then SPF) dialogues.
That helped jump-start my career when I moved on to a better job 6 months later.
While kludgy, and (possibly) inelegant, I don't find JCL that difficult.
Can it be improved? Yes.
Will it be? Business Case it!
But, stop b*tching about it.
-
Too busy driving to stop for gas!
Clark Morris
>>JCL has been criticized by those who have not mastered it since the time of OS PCP.
>
>I've been using JCL since February 1981.
>I started in this business as a JCL jockey in Production Support for a Canadian Railway Company that was building a new data centre in Toronto.
>
>While we were moving from Montreal to Toronto, we had a lot of spare time in the new Control Room.
>So, I spent a lot of time learning JCL, utilities, CLISTs, and ISPF (then SPF) dialogues.
>That helped jump-start my career when I moved on to a better job 6 months later.
>
>While kludgy, and (possibly) inelegant, I don't find JCL that difficult.
>Can it be improved? Yes.
>Will it be? Business Case it!
>But, stop b*tching about it.
While most of my experience has be MVS and DOS (real not virtual) JCL,
there were some very interesting capabilities in the Unix shell system
used at the HP/UX installation where I was a contractor. This shell
system had GDG capabilities and other things that I don't recall now.
I have also heard the work flow languages for both the large scale
Burrough computes and for the AS400 and i series make JCL look brain
dead. If the work flow language for the i series is as good as I have
heard, then there could be a good case for porting it to both the p
series and the z series.
Bernd Oppolzer
already,
which was the same for batch and dialog. No need to learn different
languages like
JCL and TSO command languages, and you could do all the things you can
do with
the JCL of today, even more (define your own commands, for example). The
usability of the Telefunken time sharing system was far better than any
other system
at this time, and even later (interactive debuggers, symbolic dumps -
with names from
the source level - and so on; things that appeared again, for me, with
OS/2 in the
1990 years).
For me and others, who worked with this machine, the IBM JCL always looked
very strange.
Kind regards
Bernd
Clark Morris schrieb:
> While most of my experience has be MVS and DOS (real not virtual) JCL,
> there were some very interesting capabilities in the Unix shell system
> used at the HP/UX installation where I was a contractor. This shell
> system had GDG capabilities and other things that I don't recall now.
> I have also heard the work flow languages for both the large scale
> Burrough computes and for the AS400 and i series make JCL look brain
> dead. If the work flow language for the i series is as good as I have
> heard, then there could be a good case for porting it to both the p
> series and the z series.
>
----------------------------------------------------------------------
Shmuel Metz , Seymour J.
at 04:29 PM, john gilmore <john_w_...@MSN.COM> said:
>JCL has been criticized by those who have not mastered it since the time
>of OS PCP.
ObQoheleth Similar complaints were no doubt made by my Uncle Crow and Aunt
Maggie.
>He begins here by attempting to distinguish a macro processor and a
>programming language, implying it would seem that a macro processor is
>not a programming language; but he then proceeds immediately to
>criticize, a little ungrammatically but unambiguously enough, both JCL
>and the HLASM as lacking two of the important attributes of programming
>languages, viz., "graceful branching" and "clean iteration".
If you compare the macro facilities of HLA and PL/I, you will be hard
pressed to justify the way that HLA does it as having "graceful branching"
and "clean iteration". Certainly AIF is better than nothing, but it is
crude.
>Someone unfamiliar with the HLASM macro language would find it
>unintelligible; and there is a familiar, now tedious perspective from
>which it is judged long-winded and/or detail-ridden; but there is
>nothing unclean about it.
This someone has been familiar with the syntax for more than 4 decades and
finds it unclean. OTOH, I'm not familiar with an assembler whose macro
language is any better.
>What distresses me about these views is not their substance, with which
>I expect usually to disagree. It is his perspective.
I can't really quarrel with that, but you also have a limited perspective.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)