Chuck, I wish I'd done a better job typing, and you're correct:
I meant to type CPF7E56 as the message id, and that the error is being diagnosed for only the final declared variable.
And to your point 'the issue remains unreported': I'll talk with our Operations manager about reporting this issue.
Thank you Chuck, I appreciate your comments.
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Friday, November 07, 2014 10:34 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: CPF7E56 Identifier is ambiguous is mysterious
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
