Re: CPF7E56 Identifier is ambiguous is mysterious

These are debugger messages - is it possible, Gary, that you have a field from a DCLF that is the same as one of these?

The 7E56 message is a name conflict, so can you look at a compile listing for the name in question and see if it appears in more than one context?

HTH
Vern

On 11/7/2014 11:34 AM, CRPence wrote:

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.