× 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.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.