> 1. I fail to see the benefit. If I code the proc with MYPARM='FOO' and then
> mistakenly code &MYPRM instead of &MYPARM in the body of the PROC, then the
> error is the undefined &MYPRM,
//SYSBAR DD DSN=&MYPRM,DISP=(MOD,PASS)
Is valid. At the time IBM defined the syntax, there were no symbolic
parameters. Changing that to invalid would break every job that used a single
ampersand for a temporary dataset name.
Do I like it? No, but that ship has sailed.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Charles Mills [charl...@mcn.org]
Sent: Thursday, December 2, 2021 3:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task
Peter, fools rush in. I will give it a shot.
Apologies if I was vitriolic. It's just a language detail! Peace and Joy!
I see the situation as exactly analogous to most languages I use. If I
declare a variable in C++ and do not ever use it then it is a non-event. If
I declare a method (subroutine) with a formal parameter that I do not use in
the method (analogous to the PROC situation I would say) then I get a
warning IIRC that may be dismissed in any of several ways. If I define a
variable in Rexx and never use it then it is a non-event. If I declare a
procedure in Rexx that does not use one of its arguments it is a non-event.
I have never heard anyone say "I wish Rexx would give me an error if a
procedure failed to reference one of its arguments."
1. I fail to see the benefit. If I code the proc with MYPARM='FOO' and then
mistakenly code &MYPRM instead of &MYPARM in the body of the PROC, then the
error is the undefined &MYPRM, not the unreferenced &MYPARM. It would seem
to me that an error on the latter is superfluous.
2. I am missing the compatibility problem. Every change is theoretically a
compatibility problem. Suppose IBM were to define a new JCL statement
DOTHIS. Well, we have a compatibility problem, right? Every job that had an
erroneous // DOTHIS in it somewhere used to fail and now it might not. QED.
But obviously that is a ridiculously irrelevant incompatibility. Isn't this
the same? Is there really a PROC somewhere with an unreferenced parameter in
it, and whose owner is counting on it failing, and who will be surprised
and/or inconvenienced if it stops failing? I suppose there might be a hasty
sysprog somewhere who is counting on the system telling him that he has an
unreferenced parameter. Would not a warning suffice for him? I would say
that if he is trying to debug a PROC he should be and probably is in fact
paying attention to the messages.
Is this error a real problem? I can tell you that it has been a real life
problem for me. Here is the situation. I am developing a PROC. I try this. I
try that. At some point I change or comment out or remove a JCL statement,
and the PROC fails because one of its parameters is now unreferenced.
Grrrrr!
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: Thursday, December 2, 2021 11:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Trying to use long parm= in started task
I am surprised at the vitriole regarding
IEFC657I THE SYMBOL xxx WAS NOT USED
Every time I have seen that message it was because the proc creator (me)
screwed up (sometimes in a subtle way).
-- Ignoring that situation does not seem to be in the user's best
interest.
-- Warning about that situation is not either because no one will notice
the warning.
-- Treating it as an error seems to me to be the right action. It has
helped innumerable people over the years.
This is quite different than a compiler, for example, optimizing out
something that proves not to be used.
This could not unconditionally be changed, for compatibility reasons. That
says that an option such as "do not treat as an error" would have to be
provided and used. Make the case that this is a good idea. None of the
posts I read did so.
Sure, one could ask for an option to "ignore" or "treat as warning" but if
you knew enough to include that option, wouldn't you just "fix" the proc
not to have extraneous unneeded stuff to help everyone not get confused?
Asking for improvement in the detection of use of a proc symbol, such as
within the ParmDD SYSIN might be reasonable. It was implemented as it was
because it was practical to do so. And the limitation that exists can be
dealt with. It is not practical to have the system search through the Parm
DD if the Parm DD is not inline so could not be done "in general". What
would you sacrifice our doing in order to accommodate? It is always fair
to ask; but it is also a requirement to understand that there are limited
resources to be parceled out among worthy causes. Maybe one could consider
an option such as "make a JCL symbol from every proc symbol, with some
naming convention" that could make it easier to use the symbols from the
proc in a Parm DD without having to do extra stuff, possibly incorporating
"EXPORT SYMLIST=*" and the option (if needed) so that JCL symbols are
processed within Parm DD (such as the current SYMBOLS=JCLONLY).
What am I missing?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
