On Mon, 28 Jul 2008 09:22:03 -0500, Jeff Holst wrote:
>On Fri, 25 Jul 2008 17:56:35 -0500, William H. Blair wrote:
>
>>Jeff Holst noted that an IBM SRL states:
>>
>>> 1. Overriding statements can appear in any order when
>>> they explicitly specify the step that is being
>>> overridden.
>>
>If you go on to read the next paragraph it explains what happens when the
>step is not specified (it uses the step name from the last DD statement that
>did specify a step name, and if none exists the first step in the proc is
>overridden.) The paragraph that follows further clarifies things by stating
>that
>overriding DD statements must appear in the order of the steps in the proc.
>
>It is misleading to take one paragraph in isolation.
>
I certainly remember (though obviously not as clearly as Mr. Blair)
a day and age when overriding DD statements were required to appear
in the same order as the overridden DDNAMEs in the proc. I was
delighted to see the constraint relaxed. It makes JCL coding
easier and more robust because it's easier to spot coding errors
because of the decreased likelihood that the coded overriding SYSIN
would have no effect.
I don't know how long ago the ordering constraint was removed -- it's
documented in 5.2.1.2 "z/OS V1R1.0 MVS JCL Reference", but surely
that's the source of most of the objections in this thread, so I'm
puzzled that there was no shrill outcry back then -- it should have
created major incompatibilities.
But the "reordering" occurs only when both DDNAMES match DDNAMES
in the overridden PROC; else at least one is an added DD statement.
Prior to the "reordering" facility, a misordering would have
resulted in a duplicate DDNAME within a step, and I read in
12.1.2 "z/OS V1R1.0 MVS JCL Reference":
12.1.2 Name Field
When specified, code a ddname as follows:
* Each ddname should be unique within the job step. ...
(yes, it then goes on to specify (partially) the effect of duplicate
DDNAMES within a step, including different behavior for JES3 and
JES3). So programmers who relied on the duplicate SYSIN introduced
by the GENERATE STATEMENT were at least ignoring a "should" and
"should" have recognized their behavior as risky and perhaps not
portable between JES2 and JES3.
I find the whining about APAR OA05951 simply incredible. As I read
it, prior to the fix, contents of various instream data sets were
treated positionally, ignoring the specific DDNAMES. With the fix,
the content matches the DDNAMEs. I can see this only as repair of
a blatant Programming ERror.
Finally, I mostly concur with Tom Marchant's reply to Mark Zelden's
"What's wrong with comments?" I use the bogus DDNAME largely to
select among different versions of SYSIN for development and
testing. One exception is when I have a large header comment.
Then I may use:
//DOC EXEC PGM=IEFBR14
//COMMENTS DD *
Text that I can easily reflow and reformat.
I suppose that if I were more proficient with ISPF's
facilities for limiting column ranges and reformatting
text, I would use those instead. But yet, it avoids
the distraction of the "//*" for the reader.
I'll sometimes disable a lot of JCL with IF. Which is why I regret
that "IF FALSE" is documented as not supported and unpredictable
in behavior (although no error is reported and the construct has
(almost) the intuitive effect).
-- gil
----------------------------------------------------------------------
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
