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/

Reply via email to