|
Carel Teijgeler wrote on 16/11/2006 04:25:05 PM:
In the second example DAYS1 is seen and treated as a character parm "DAYS1".
Really?! I'm very surprised by that ... most other languages I can think of insist on character literals being delimited in some way, to differentiate them from variables. Thinking about it from the point of view of 'what would I actually type on the command line', I guess it sort of makes sense. However, if the compiler won't let me do: CHGVAR VAR(var1) VALUE(&A + myCharLiteral + &B), I'm not really sure why it would let me use a non-delimited character literal in any context in a compiled program.
I have a CL program that was causing a very strange error. The CL hasthis 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 aeitherCALL PGM(pgmA) PARM(&VTYPE &UTERM &DAYS1), which worked just fine, or CALL PGM(pgmA) PARM(&VTYPE &UTERM DAYS1) which doesn't work.
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.
Actually, those source snippets are in the same CL, and pgmA is an RPG program. Thanks for informing me that variable names are considered character literals on CALLs when the & is forgotten. Adam ##################################################################################### Attention: The above message and/or attachment(s) is private and confidential and is intended only for the people for which it is addressed. If you are not named in the address fields, ignore the contents and delete all the material. Thank you. Have a nice day. For more information on email virus scanning, security and content management, please contact administrator@xxxxxxxxxxxx #####################################################################################
As an Amazon Associate we earn from qualifying purchases.
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.