Re: CPF7E56 Identifier is ambiguous is mysterious -- MIDRANGE-L

Gary

Sorry if I seem ornery - there has to be something else with the same names in your program - your comment says "map parameter values" - are these *DEFINED variables used as the incoming parameters?

Now the ornery part - don't use EVAL yet - not before you look at the compile listing.

I put the code you have here into a program and compiled it - the only thing I had in the program other than this was RTVDTAARA - I don't know what your code is, of course.

No ambiguous Identifier message in debug - so please check the compile listing - or give us a complete source listing, with the bits that we are allowed to see by your security policies - maybe modify things so we can see them.

Here's the code I used -

PGM
/* Start: hold data area LCP972DA and map parameter values ---------*/
DCL VAR(&DACHAR) +
TYPE(*CHAR) +
LEN(90)/* text from LCP972DA */
DCL VAR(&ENDHH) +
TYPE(*CHAR) +
STG(*DEFINED) +
LEN(02) +
DEFVAR(&DACHAR 01)/* End Hour, 24 hour fmt */
DCL VAR(&ENDMM) +
TYPE(*CHAR) +
STG(*DEFINED) +
LEN(02) +
DEFVAR(&DACHAR 04)/* End Minute, 00-59 */
DCL VAR(&WAITSEC) +
TYPE(*CHAR) +
STG(*DEFINED) +
LEN(03) +
DEFVAR(&DACHAR 41)/* Wait Seconds, 000-999 */
DCL VAR(&ENDJOB) +
TYPE(*CHAR) +
STG(*DEFINED) +
LEN(03) +
DEFVAR(&DACHAR 85)/* END = End Job */
DCL VAR(&LASTCH) +
TYPE(*CHAR) +
STG(*DEFINED) +
LEN(01) +
DEFVAR(&DACHAR 89)/* dont need, dont use */
/* End : hold data area LCP972DA and map parameter values ---------*/
RTVDTAARA DTAARA(DP2TEST/LCP972DA) +
RTNVAR(&DACHAR)
ENDPGM

HTH
Vern

On 11/7/2014 5:30 PM, Gary Thompson wrote:

Vern,
I agree, it seems very likely there is something wrong with my CL.
There is no DCLF in this CL.
However, why would adding another DCL statement 'move' the 7E56 message to the 'next' DCL statement ?

I'll start here:
/*‚ Start: hold data area LCP972DA and map parameter values ---------*/
DCL VAR(&DACHAR) TYPE(*CHAR) LEN(90) /* text from LCP972DA */
DCL VAR(&ENDHH) TYPE(*CHAR) STG(*DEFINED) LEN(02) DEFVAR(&DACHAR 01) /*End Hour, 24 hour fmt */
DCL VAR(&ENDMM) TYPE(*CHAR) STG(*DEFINED) LEN(02) DEFVAR(&DACHAR 04) /*End Minute, 00-59 */
DCL VAR(&WAITSEC) TYPE(*CHAR) STG(*DEFINED) LEN(03) DEFVAR(&DACHAR 41) /*Wait Seconds, 000-999 */
DCL VAR(&ENDJOB) TYPE(*CHAR) STG(*DEFINED) LEN(03) DEFVAR(&DACHAR 85) /* END = End Job */
DCL VAR(&LASTCH) TYPE(*CHAR) STG(*DEFINED) LEN(01) DEFVAR(&DACHAR 89) /* dont need, dont use */
/*‚ End : hold data area LCP972DA and map parameter values ---------*/

I just now re-compiled the CL in question and ran in DEBUG and get the following:
EVAL &ENDJOB
&ENDJOB = 'RUN'

And this on &LASTCH:
Identifier is ambiguous

Ok, one another demo:
I'll comment-out &LASTCH:
/*‚ Start: hold data area LCP972DA and map parameter values ---------*/
DCL VAR(&DACHAR) TYPE(*CHAR) LEN(90) /* text from LCP972DA */
DCL VAR(&ENDHH) TYPE(*CHAR) STG(*DEFINED) LEN(02) DEFVAR(&DACHAR 01) /*End Hour, 24 hour fmt */
DCL VAR(&ENDMM) TYPE(*CHAR) STG(*DEFINED) LEN(02) DEFVAR(&DACHAR 04) /*End Minute, 00-59 */
DCL VAR(&WAITSEC) TYPE(*CHAR) STG(*DEFINED) LEN(03) DEFVAR(&DACHAR 41) /*Wait Seconds, 000-999 */
DCL VAR(&ENDJOB) TYPE(*CHAR) STG(*DEFINED) LEN(03) DEFVAR(&DACHAR 85) /* END = End Job */
/* DCL VAR(&LASTCH) TYPE(*CHAR) STG(*DEFINED) LEN(01) DEFVAR(&DACHAR 89) just for Vern */
/*‚ End : hold data area LCP972DA and map parameter values ---------*/

I did another compile/debug and now get:
EVAL &ENDJOB
Identifier is ambiguous

Still mystified . . .

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Vernon Hamberg
Sent: Friday, November 07, 2014 10:42 AM
To: Midrange Systems Technical Discussion
Subject: 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.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.