×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 07-Nov-2014 09:14 -0600, Gary Thompson wrote:
<<SNIP>>
I'm not sure reserved word conflict is the case or cause,
Doubtful that the variable name [the undelimited token] "&ENDJOB" is
a reserved word. And almost certainly, not every other OS [and LPP, and
user-defined] command name would be a "reserved word" in the system
debugger; even if the /word/ after the ampersand were reserved [for
another reason than being a possible *CMD name in *LIBL], then the fact
that the variable name actually *includes* the ampersand, suggests that
the token is clearly _unambiguous_ with respect to any command name.
mainly because after adding &LASTCH _after_ &ENDJOB, I no longer
receive CPF7E15 on &ENDJOB,
Presumably that meant to suggest "no longer receive CPF7E56 on &ENDJOB".?
but do receive CPF7E15 on &LASTCH.
The OP had suggested that the CPF7E56 [re ambiguous] had migrated to
the variable name "&LASTCH", so presumably the above also meant to note
the msg CPF7E56 rather than msg CPF7E15?
I tested with &AB_CD9 as the name and received CPF7E315.
Presumably CPF7E15 was intended.? Though I am thinking more likely
not, and just like each of the prior message id notations, the intent
might have been to note the same message as in the subject; i.e.
CPF7E56? Or instead of the same message for the next variable, the
actual message being diagnosed has changed?
Anyhow, does the description of that test imply "&AB_CD9" was used in
place of the "&ENDJOB", or in place of the "&LASTCH"? And was the error
always diagnosed for only the final declared variable, irrespective the
[preceding] variable names?
At any rate, this code is part of a project I'm testing for
production, and &LASTCH is only used as a DCL, so I'm moving on,
. . . mystified.
Recorded as an archived discussion is somewhat helpful to someone
else, but the issue remains essentially uninvestigated and the issue
remains unreported in a manner that might diminish the travails of others.
One might consider the poor schmuck who deletes the variable that
seems to have no value, per appearing "only used as a DCL" without any
other conspicuous purpose; after which, they [and worse, "they" might
even be "I"] experience the _same difficulty_ because whatever was the
issue, persists.
midrange.com
