Paul Gilmartin wrote:
On Sun, 3 Jan 2010 11:28:18 -0400, Clark Morris wrote:
JCL was designed for OS360 on a 256K real machine (the original design
point for PCP was 64K). In addition, I suspect that the design was
done by engineers or mathematicians for whom "not and" and "not or"
were familiar concepts. Virtually all of the printers were upper case
only and at least in my shop it was a struggle to get a printer that
printed the special characters correctly (the 48 character train was
adequate FSVO adequate). Lower case was out of the question. Memory
and instruction cycles were at a premium. Even on a 1 megabyte mod 65
we were stingy about region sizes.
The inhomogeneity of JCL syntax is symptomatic of lack of reusable
subroutines. A reusable lexical analysis subroutine would have
alleviated the memory constraint while supporting resolution of
symbols wherever they appear (but perhaps not in SYSIN, which is
a different matter).
Does anyone know a plausible design rationale for the current
restrictions on symbol substitution?
Rather, I ascribe it to Conway's law at its perniciousest. Design
and coding of parsers for the various JCL operands was parceled out
to different programmers. Each could decide independently whether
to support symbol substitution. Since there was (apparently) no
reusable lexical analysis subroutine, support for symbol substitution
would have required considerable extra code in each context, and
was provided only where the need was most urgent.
While I share your (Paul's) distaste for JCL, the crime is that IBM
hasn't provided a clear migration path for at least new things to
either REXX or one of the shells. It also hasn't provided a migration
Rexx, I'd say. Once again, the deficiencies I perceive in Rexx are:
o Lack of a bulk ENQ with WAIT facility to prevent deadlocks, one
thing JCL does well.
o Lack of support for APF authorized subcommands, though this can
mostly be achieved when Rexx runs under the TSO TMP.
o (For me particularly) Lack of support for multi-file tapes by
keyword/constructs such as RETAIN, PASS, and VOL=REF.
path so that we could have longer member names, longer data set names
The longer names are available in the Unix filesystems. A plausible
migration path would be providing for migration of enterprise data
into Unix filesystems.
Cool! I'm working on an utility to do that! In a month or two I
could use some beta testers.
and a generation data set facility for ESDS data sets. We are stuck
on software architecture that was designed for the limitations of the
original 360's using work arounds and kludges. It is for this reason
Most of that last is more fundamental than JCL.
that I am not optimistic about the long term viability of the z series
and z/OS.
I wonder if IBM is listening? I wonder if IBM doesn't see it a
sounder business position to cannibalize rather than nurture z/OS?
-- gil
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques
==> Ask about being added to our opt-in list: <==
==> * Early announcement of new courses <==
==> * Early announcement of new techincal papers <==
==> * Early announcement of new promotions <==
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
