They actually did use reserved words in their EQUATES, where Universe did not
do this sort of
replacement, and the target environment behaves like Unidata, causing some
code (not an awful amount) to fail compilation. Another lesson here -
don't use words that even look like they should be
@listserver.u2ug.org
Sent: Friday, April 06, 2007 6:57 PM
Subject: RE: [U2] [UD] Dynamic variable. Kids, Don't try this at home!!!
You can come up with some bizzare and totally unportable code in unidata
using equates:
EQU READNEXT TO 12345
ID='2R'
LOOP WHILE READNEXT ID DO
CRT READNEXT ID
CRT ID
, Stuart [EMAIL PROTECTED]
To: u2-users@listserver.u2ug.org
Sent: Saturday, April 07, 2007 9:37 AM
Subject: RE: [U2] [UD] Dynamic variable. Kids, Don't try this at home!!!
They actually did use reserved words in their EQUATES, where Universe did
not
do this sort of
replacement, and the target
Ed wrote:
Just discovered something kinda cool that I want to share:
Here are a set of equates:
004:EQU TEF.TOTAL.VAL TO SUM(TEF.VAL)
0009: PRINT TOTAL = :TEF.TOTAL.VALR#3
0010: PRINT SUM= :SUM(TEF.VAL)R#3
When you run this, the variable TEF.TOTAL.VAL always knows the
TEF.TOTAL.VAL isn't a variable. For the most part, equates are just
replacements. Everywhere you have TEF.TOTAL.VAL in your code gets replaced
with SUM(TEF.VAL) so
TEF.TOTAL.VAL=0
Becomes
SUM(TEF.VAL)=0
Which of course is illegal and won't compile.
You can see the replacements at work with vlist.
Sorry, I mentioned vlist in my previous response. That's a universe thing. I
don't know if there's an equivalent in unidata. Universe/unidata differ in
what they will accept in an equate. I know jbase differs. Something like
this:
0001 C=0
0002 EQU A TO CHAR(C
0003 C=1
0004 *note I left the
Thanks for the code, Ed and Ed. Indeed, don't try this at home. They're
doing basic macro expansion, which we do with pre-processors all the time,
but it's just not portable in app code. The issue is that some compilers
will evaluate the expression of an EQUATE, then embed the result into the
