Re: Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc
Anne & Lynn Wheeler
PaulGB...@AIM.COM (Paul Gilmartin) writes:
> So that's where CMS got that idea. But z/OS device independence is eroding.
> Why are there TPUT/TGET/PUTLINE/GETLINE (whatever) rather than just doing
> QSAM I/O to SYSTSPRT and SYSTSIN? And I'm dismayed at the number of z/OS
> utilities that balk at "DD PATH=...", not because their QSAM calls couldn't
> perfectly well handle it, but merely because they're afraid to try.
a lot of CMS design reflects CTSS heritage. CMS then adopted a lot of
os/360 applications ... and therefor had to do a layer of OS/360
simulation (especially for assembler and compilers).
more information ... cp67/cms version 3 (oct70) users guide:
http://www.bitsavers.org/pdf/ibm/360/cp67/GH20-0859-0_CP67_Version_3_Users_Guide_Oct70.pdf
os macros .... pg 294
Later after the moph to vm370/cms (and cambridge monitor system renamed
conversational monitor system) ... there was some amount of DOS
simulation also added. There was also some joke about CMS 32kbyte
os/360 simulation code ... did almost as good as the 8mbyte mvs os/360
simulation code.
The biggest change from cp67/cms to vm370/cms ... was reorging the
kernel with application program loading at x'12000' to take advantage of
(original) 370 (64k) r/o shared segment support. Application programs
then were moved to starting at x'20000' ... and cms kernel "shared code"
moved to start at segment boundary at x'10000' (segment 0 was then data
and non-shared code ... since virtual page zero couldn't be shared, and
therefor virtual segment 0 couldn't be shared).
however, all the effort came to *NOT* ... before the full 370 virtual
memory architecture could be announced and shipped ... retrofitting the
full 370 virtual memory architecture to 370/165 ran into all sorts of
problems. 165 petitioned for dropping several features to gain back a
lot of the schedule; and one of the things dropped was 370 r/o shared
segment support. that forced m370 to quickly come up with a quick&dirty
hack using storage protection keys ... to simulate the original 370
virtual memory r/o segment protect.
with the addition of dos simulation ... for running dos programs in cms
... there then had to be option to specify whether non-cms service
requests went thru os simulation or dos simulation ... aka "set dos on"
http://publib.boulder.ibm.com/infocenter/zvm/v5r4/topic/com.ibm.zvm.v54.dmsa5/hcsd2b00514.htm
in the wake of demise of FS and the head of POK convincing corporate to
kill vm370, shutdown the burlington development group and moving all the
people to POK (justification was that otherwise wouldn't be able to make
mvs/xa ship schedule) .... there was joke that head of POK was major
contributor to vax/vms (i.e. the people that didn't move to pok ... but
went to DEC to work on vax/vms); endicott eventually was able to obtain
the vm370 product mission ... but had to reconstitute the organization
from scratch.
the issue here was that one of the people in burlington (that didn't
move to pok) had done a pretty complete os disk i/o routines for os disk
r/w, vtocs, handle most kinds of files, understood and could process
PDS, etc (aka wasn't os/360 file simulation in cms filesystem, but
supported full os/360 operation on os/360 disks). All of that
evaporated/disappeared with the shutdown of burlington development
group.
--
40+yrs virtualization experience (since Jan68), online at home since Mar1970
hanc...@bbs.cpcn.com
> the issue here was that one of the people in burlington (that didn't
> move to pok) had done a pretty complete os disk i/o routines for os disk
> r/w, vtocs, handle most kinds of files, understood and could process
> PDS, etc (aka wasn't os/360 file simulation in cms filesystem, but
> supported full os/360 operation on os/360 disks). All of that
> evaporated/disappeared with the shutdown of burlington development
> group.
Per the question of the subject line, I believe the original developer
of JCL, Mr. Brooks, himself said it was a lousy language but it was
the best they could do under the circumstances of rushed development
of a complex new idea. ("The birth of a baby will take nine months no
matter how many women are assigned", and "Adding more people to a late
project will only make it later.")
Considering the incredibly many options and internal communications
shortcuts, it is pretty powerful. However, I'd rather spell things
out than depend on backward references, especially in procs, for ease
in understanding. Some of the substitution options in procs can get
confusing.
JCL includes a way to check the 'condition code' of a prior step.
Most of the time it's to see merely that a prior step didn't abend.
But all sorts of convoluted logic can be done on the COND= clause
which are very hard to understand.
Anne & Lynn Wheeler
> Per the question of the subject line, I believe the original developer
> of JCL, Mr. Brooks, himself said it was a lousy language but it was
> the best they could do under the circumstances of rushed development
> of a complex new idea. ("The birth of a baby will take nine months no
> matter how many women are assigned", and "Adding more people to a late
> project will only make it later.")
re:
http://www.garlic.com/~lynn/2010.html#22 Why is JCL so bad was Re: Basic question on passing JCL set symbol to proc
the thread originated in ibm-main ... and I added in a.f.c. earlier in
the (ibm-main) part of the thread there. can be viewed in google groups:
http://groups.google.com/group/bit.listserv.ibm-main/browse_thread/thread/8fb4c75d62fc6353/b31fc2570a47f078?q=why+is+jcl+so+bad+group:bit.listserv.ibm-main#b31fc2570a47f078
one of the earlier posts (by somebody else) starts out with:
I transcribed this from a talk given by Fred Brooks, Jr. on the 40th
year anniversary of the System 360. This is a wonderful talk given by
the people who were involved in the original design, recorded at the
Computer History Museum. This is what Fred Brooks said about JCL:
... snip ...
and then goes on for a couple paragraphs