Not for nothin' but I believe there's more to the variable assignment version of an equate than you've expressed.
In essence, there are 2 kinds of EQUATES. The first style, sometimes known as an alias, is like your EQUATE APFILE.BALDUE TO APFILE.REC(2) and you can manage the contents of the second field in the A/P record either using the left portion of the TO or the right. The second style is more on the compiler level and not a simple variable assignment. EQUATE TRUE TO 1 causes the compiler to replace the expression TRUE inside the source code with the literal value '1'. Then it compiles. This is different than TRUE=1 which occurs at run-time. Quite frankly I really, really don't think the assignment version matters with today's processors. This theory has been around since Jurrasic Pick and may have made more of a difference back then. Today, saving 5-10 cpu cycles per second is drop-dead useless regardless of how many users there are. Even on a 500 user system, that's 5,000 savings against 2,800,000,000. Hardly noticable. Only the lunatic fringe or purely academic can support that argument. I think the EQUATE TRUE TO 1 comes from a taught programming discipline from a long time ago and, like many learned things, isn't bad so it doesn't need replacing. But I don't think it's necessary. EQUATE CUSTNAME TO 1 falls into the same assignment category. This borders more on documenting the program than programming in it. Technically speaking, you're wasting time with an equate like this as many times the programmer will use PRINT CUSTREC<1> and the pre-compiler would have wasted those few precious cycles replacing the text CUSTNAME with the digit 1. Thus the argument should be had for the human programmer's effeciency and not the program's. Before the flames come, I'm not endorsing bad coding. But to have EQUATE CUST.AR.BAL TO 49 at the top (or buried in an INCLUDE) and trying to debug (or read) a program with a problem in that area means more work for me. Considering that the editor is purely numeric, if field 49 is screwed up somehow and I have a program filled with indirect references, I have to print out that roadmap to see the reference. Plus there is a good chance (except for Manage-2000 I guess) that the outside dict names don't always (or can't) be used for internal variable names. There's a dozen ways to express CUSTOMER NAME and only one way to express '1'. I remember a senior programmer in 1978 printing out the map of the compiled program and trying to insure that a FOR...NEXT loop fell within the boundaries of a single object code frame. That's inconcievable today. BTW, I don't subscribe to EQUATEing variables (nor alias's for that matter) as my client's code is far too scattered to introduce this level of overhead. My INCLUDE SETUP is all equal signs and I don't use File Defining INCLUDES unless the entire (or virtually entire) application is that way (Primac). Thus I guess I am a keeper of the standard manual coding styles. One other thing. I know where the $ in BELL$ came from but tell me why you use it. I've seen it before in SAS but never have used it in any MV programming except if previously used. Just interested, that all. Mark Johnson ----- Original Message ----- From: "Bill_H" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, August 12, 2005 8:35 PM Subject: RE: [Maybe spam] RE: [U2] Remove Scenario > Mark: > > I've said this before many times. Use equates when you later want to alter > one or another side of an equality. For example: > > EQUATE APFILE.BALDUE TO APFILE.REC(2) > > but don't use an EQUATE to simply assign a value. For example: > > EQUATE BELL$ TO CHAR(9) > > If you want to assign a variable simply: > > BELL$ = CHAR(9) > > This solves a lot of confusion. > > Bill > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Mark Johnson > > Sent: Friday, August 12, 2005 4:32 PM > > To: [email protected] > > Subject: Re: [Maybe spam] RE: [U2] Remove Scenario > > > > I'll go out on a limb here and make a conclusive opinion. > > > > I don't like EQUATES inside of a program. That doesn't mean I > > don't like EQUATES. I just don't like them as some form of > > higher programming when they are in a program. > > > > I do like them in a consistent manner and the way to make > > them consistent is in an INCLUDE. Thus have a SETUP include > > that has all of the housekeeping crap like EQUATE TRUE TO 1, > > FALSE TO 0 EQUATE AM TO CHAR254, 253, 252 ETC PROMPT "" > > EQUATE BELL TO CHAR(8) > > blah, blah, blah. > > > > and then have your file-defining EQUATES in their own single > > INCLUDE. Thus the filehandle, DIM size and all of the things > > you are trying to normalize are consistent. > > > > Like before, I've seen too many scattered examples of > > half-baked ideas of EQUATES that really don't impress me > > much. Sometimes I see one or two EQUATES like EQUATE CUSTNAME > > TO 1 EQUATE PRODDESC TO 6 > > > > and they're used properly but in the same program you see: > > > > PRINT CUSTREC<CUSTNAME>"L#30":" ":CUSTREC<49>"D2/" > > > > C'mon. Either all or none at all. > > > > That begs the question. EQUATE the attribute number for a > > dynamic array (compiler replacement) or EQUATE the field for > > a dimensioned array, (alias concept). I've seen many examples > > of both but I think they lean more towards the DIM variety. > > And the survey says....... > > > > Thanks. > > > > ----- Original Message ----- > > From: "Marilyn Hilb" <[EMAIL PROTECTED]> > > To: <[email protected]> > > Sent: Friday, August 12, 2005 2:48 PM > > Subject: RE: [Maybe spam] RE: [U2] Remove Scenario > > > > > > > I am on MasterPack. Whenever I 'deliver' a modification with a > > > dictionary > > on it from one system to another, that process actually > > re-builds the equate includes for any new dictionary item I > > may have added. So yup, got lots of these, but not something > > I or any recent programmer before me did intentionally. > > > > > > > > > -----Original Message----- > > > From: Mark Johnson [mailto:[EMAIL PROTECTED] > > > Sent: Friday, August 12, 2005 1:35 PM > > > To: [email protected] > > > Subject: Re: [Maybe spam] RE: [U2] Remove Scenario > > > > > > 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/ > > > ------- > > > 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/ > ------- > 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/
