You'd hate Manage-2000. Their DICT.BUILD creates a MFG.LAYOUTS file which creates two INCLUDES for each file. All the dict items are prefixed with the file name, and then the rest of the dict item is at the end. And the standard at which all programmers are forced, er...*encouraged* to use mandate these includes for each file.
So everything is like: IF CM.Credit_Limit > ARH.Dollars_Outstanding THEN blablabla Makes is a real PITA to work with sometimes. Especially when you have everything memorized by the attr#, and now you have to remember sometimes very similar names for fairly different dict items. And the same for the DEBUG, you'll get a symbol not found and then have to put in CM.REC<XX> so it really forces you to have to remember or keep a cheat sheet handy when debugging. fwiw....Allen -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mark Johnson Sent: Friday, August 12, 2005 16:32 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/
