On Tue, 19 Jun 2012 07:40:22 -0500, McKown, John wrote:
>
>As an example of trying to get programmers to do a minor change, at another
>shop, we used CA-JCLCHECK. I made it flag accepted but obsolete parameters,
>such as SEP=. The amount of screams from some of the programmers was
>deafening. I literally got told by one "I've been coding that for 25 g-d damn
>years and I'll be damned if I'm going to stop now. Turn the <redacted> message
>off or I'll <redacted> out your <redacted>."
>
The consequence/alternative is that as such experts in
obsolete arcana age out they're irreplacable. Newcomers elect
to learn friendlier languages. And IT executives consider this
in making system purchase decisions. You've discussed the
consequence repeatedly.
I have an anecdote similar to yours. I once instucted a colleague
about my chronological age, but with five more years JCL experience
to accomplish a certain task by coding:
//SYSIN DD PATH='whatever', RECFM=FB, LRECL=80,...
"Don't you mean, '...DCB=(RECFM=FB, LRECL=80),...'?"
"No."
He insisted on coding "DCB=(...)". Didn't work.
"I told you so!"
He _grudgingly_ accepted my original suggestion. Yet, like him,
I wonder why the JCL designers stupidly elected to make PATH
and DCB mutex.
For control block compatibility, I wonder how much of this could
be achieved for multi-level PROC calls by substituting translator-
generated symbols for the job step and proc step names?
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
