I'll add another localized comment from my experience. My client with the 17 different expressions of CUSTOMER NAME actually had 17 versions of
EQUATE CUST.NAME.ATTRIBUTE TO 1 EQUATE CUSTOMER.NAME.ATT TO 1 EQUATE CNAME.ATR TO 1 etc. So I still stand by my original belief that if these EQUATES are localized as in this example, then you are missing the point and only adding to the confusion. You cannot remember which version is in each different program without going to the top of the program to find it. Only by having these EQUATES in an application-wide INCLUDE concept can its value be realized. Otherwise, it's just another half-baked inconsistent method. My 1 cent. Mark Johnson ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, August 12, 2005 1:27 PM Subject: Re: [Maybe spam] RE: [U2] Remove Scenario > In a message dated 8/12/2005 6:00:10 AM Pacific Daylight Time, > [EMAIL PROTECTED] writes: > > > > Thank you for clearing up the issue of using EQUATES. I was ready to pile > > on you along with Les Hewkin. We use EQUATES and live by what they > > describe. I have learned never to trust DICTS. > > The only problem being (or at least last time I checked) was that RAID > doesn't understand EQUATES. So you're walking through the code and see > CUST.ADDRESS = '' > and you type > */CUST.ADDRESS > and it says whatever something like "variable not found" or something I > forget. > > So is there a downside to using a construct like > A.CUST.ADDRESS = 40 > CUST.REC<A.CUST.ADDRESS> = "" > > Then RAID is quite happy with it. > > Will Johnson > ------- > u2-users mailing list > [email protected] > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
