MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » November 2006

Re: CL compiled, but I don't think it should have



fixed

Adam,

In the second example DAYS1 is seen and treated as a character parm
"DAYS1".

In both cases you do not pass &PTERM, which means that  parm &DAYS1 will
have not a pointer set (MCH3601) when referenced in the CLP.

Regards,
Carel Teijgeler

*********** REPLY SEPARATOR  ***********

On 16-11-2006 at 16:18 AGlauser@xxxxxxxxxxxx wrote:

I have a CL program that was causing a very strange error.  The CL has
this at the beginning:
PGM        PARM(&VTYPE &PTERM &UTERM &DAYS1)

DCL        VAR(&VTYPE) TYPE(*CHAR) LEN(3)
DCL        VAR(&PTERM) TYPE(*DEC) LEN(3)
DCL        VAR(&DAYS1) TYPE(*DEC) LEN(3 0)
DCL        VAR(&UTERM) TYPE(*DEC) LEN(3)


Depending on which location the report was requested from, there was a
either

CALL       PGM(pgmA) PARM(&VTYPE &UTERM &DAYS1),

which worked just fine, or

CALL       PGM(pgmA) PARM(&VTYPE &UTERM DAYS1)

which doesn't work.

My question is, how did the value DAYS1 pass through the compiler.  This 
is not a valid variable reference (no & prefix), nor is it a valid 
character literal (not enclosed in ' ').  Can anyone explain to me why the

compiler didn't catch this?







Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact