Bill, So what you are saying is that it is bad usage of the equate statement even though it can be done. I agree and the '=' is used more often for this type of equation. However, this program was created 15 years ago (long before I started here) and had been working fine until the code was changed with the variable being inserted instead of the raw character causing us to wonder about why. The program is back to the way it was and is working fine. We just thought we could get an explanation from someone on the list as to why it made a difference and maybe let some of you all out there know to watch out for these little quirks of the language. Jerry
-----Original Message----- From: Bill Haskett [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 23, 2007 9:11 PM To: [email protected] Subject: RE: [U2] curious EQUATE issue - SOLVED Just want to know if anyone understands WHY? Jerry: I hate to mention the obvious, but one should not equate anything unless they intend both sides of the equate to change when either variable changes. For instance, DIM MYREC(30) EQUATE MYREC.DATE TO MYREC(1) EQUATE MYREC.NAME TO MYREC(2) --etc-- Thus, whenever MYREC changes, due to a new record read, so does MYREC.DATE, etc. Alternatively, you simply have to alter MYREC.DATE to make sure the MYREC record has been changed too. To fix the problems you've encountered try: VALID.CC.TYPES = 'A':@VM:'B':@VM:'D':@VM:'M':@VM:'S':@VM:'V' VALID.CC.NAMES = 'American Express':@VM:'Carte Blanche':@VM:'Diners Club':@VM:'Mastercard':@VM:'Discover':@VM:'Visa' ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
