I found the experience of being 'beaten up' drole, and I am of course
unrepentent.
It will he helpful to go back in time to the early years of OS/MFT for the
System/360. The syntax of JCL is of course modelled on that of the F
Assembler, and its macro phase in particular. JCL statements then had and
still have parameters of two sorts, positional and keyword. What was
different then was that, even for keyword statement parameters, no mechanism
for replacing their values individually was made available unless those
values were also parameters of a cataloged procedure.
To change any portion of a statement in such a procedure, it was necessary
to replace that statement with another complete one, and it was in this
context, that of suppressing undesired output, writing it to Orwell's
'memory hole', or ignoring undesired input, raising endfile on the first
read, that the agreeably brief complete statement
//<ddname> DD DUMMY
was made available. Worth noting explicitly are that (a) DUMMY is here a
positional parameter and that (b) it was devised for use outside a procedure
in order to alter the behavior of that procedure on occasions when its
standard/default behavior was unsatisfactory.
Let me also note that, while there is some similarity between the positional
and keyword parameters of a JCL statement and those of an assembly-language
macro instruction or the corresponding macro definition, there is a crucial
difference too. An HLASM macro definition may have both, and they may be
specified in any order in a corresponding macro instruction.
Thus, for example, the macro definition
macro
example &pos1,&pos2,&key1=,&key2=,&key3=
. . .
mexit
mend
can be invoked my any of the three functionally equivalent macro
instructions
example 1,key2=5,key1='hubris',key3=yes,21
example key1='hubris',key2=5,key3=yes,1,21
example 1,21,key1='hubris',key2=5,key3=yes
and many others as well. Positional arguments in a macro instruction are
mapped to the positional parameters of a macro definition from left to right
and keyword parameters are order-insensitive. Moreover, JCL did not then
have and still does not have any analogue of the HLASM's &SYSLIST facility,
which permits positional arguments to be picked off in logical sequence no
matter where they appear in a macro instruction.
Once written within a procedure neither of the DD statements
//<ddname> DD DUMMY
or
//<ddname> DD DUMMY, . . .
can be altered into one that in fact is functional, permits non-null outputs
to be written or non-null
inputs to be read.
On the other hand
//SYSPRINT DD DSN=NULLFILE,BLKSIZE=0,LRECL=137,RECFM=VBA
can be altered readily by simply supplying a different licit value of DSN=.
This
difference was the basis for my statement that DSN=NULLFILE was superior to
DUMMY when used inside procedures.
The question what is retained and what is not retained from these two dif-
gerent statements is more complicated. Different bindngs obtain for
different uses.
Volker Bandke's example is entirely correct, but what it establishes---which
was never in contention---is that textual DCB information from one DD
statement can
be 'copied' by reference into another DD statement at parse time. It does
not
address the other, in my view more important, question of what is put into
control blocks.
Moreover, while Volker's example served to establish his point, that point
is not as I unbderstand it
a functionally interesting one. If, say, one wants, N instances of the same
DCB information, this is
better accomplished by coding one operational DCB in extenso and using N - 1
references than it is
by coding one non-operational DD statement that provides DCB= values (or
their functional
equivalents) and N others that acquire this information by reference.
Finally, I want to say something about my notionally 'ex cathedra'
pronouncemnts.
I don't believe in arguments from authority of the form 'Things are thus
because I say so'.
Quos deus perdere vult amentat. Anyone but the Pope needs to be safely dead
to make
such an argument.
On the other hand, I am almost equally suspicious of simplistic alternatives
to such arguments. The opinions of the competent and the incompeternt are
not
equally valuable; and in particular, the opinions of those who are exhausted
by their never successful attempts to follow an ordered exposition of any
length have little merit. This forum is not, or at least should not be, a
talk show.
John Gilmore
Ashland, MA 01721
U.S.A.
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
----------------------------------------------------------------------
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
