Interesting. Especially since I have the distinct pleasure of sharing a
cubicle wall with one of the original Primac developers.
And while the "cpylibs" work as $INCLUDEs now, we still use cpylib from
force of habit.
--
Dave Walker
8..7 4(()) -:&:-
-:&:- 8.74 .74(())
((88.74 ..74 -:&:-
((88.74 * Peace
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Mark Johnson
> Sent: Friday, August 12, 2005 2:22 PM
> To: [email protected]
> Subject: Re: [Maybe spam] RE: [U2] Remove Scenario
>
>
> I agree here. If I had the luxury of writing a complete new
> application, I
> would borrow from my Primac experience and use
>
> INCLUDE FILE.DEFS CUSTOMER
>
> which contains
>
> OPEN "CUSTOMER" TO F.CUSTOMER ELSE STOP (sic)
> DIM CUST.REC(100)
> EQUATE CUST.NAME TO CUST.REC(1)
> etc
>
> which virtually forces a uniform nomenclature for the opening
> of the file
> (named commons not withstanding), the read-in REC and
> consistent field names
> throughout the application.
>
> While many of my clients have bits and pieces of these
> concepts, it's still
> a scattered mess of crap when it's not application-wide. Primac was so
> advanced that they didn't wait for MV to come out with the
> INCLUDE concept.
> They wrote their own with a pre-compiler that assembled the
> code. Pretty
> impressive for 1982.
>
> I choose not to use these methods as since my clients (except
> those with
> Primac) already have so many half-baked disciplines, what's
> one more. And
> while it could be argued that I'm only adding to the fire, I
> am the current
> cook in the kitchen. I see so much mis-guided code in my
> travels that I feel
> pretty good with my own rather direct form of coding.
>
> One mis-use of these Equates was on the per-program level and the
> application had this throughout their programs:
>
> EQUATE CUSTNAME TO CUST.REC(1)
> EQUATE CUST.NAME TO CUSTOMER(1)
> EQUATE CNAME TO C(1)
> EQUATE CUSTNAME TO DATA.CUSTOMER(1)
> EQUATE CUSTOMER.NAME TO CUSTOMER.REC(1)
> etc
>
> I can't recall now but there were 17 different expressions
> for the first
> attribute in the customer file throughout all the programs.
> Thus, the local
> use of these equates is just as bad as not using them. Given
> that there are
> many ways to abbreviate CUSTOMER NAME, it's hard to remember
> which gets used
> when.
>
> That's my 2 cent son local equates. Global equates are more preferred.
> Mark Johnson
> ----- Original Message -----
> From: "Les Hewkin" <[EMAIL PROTECTED]>
> To: <[email protected]>
> Sent: Friday, August 12, 2005 4:40 AM
> Subject: RE: [Maybe spam] RE: [U2] Remove Scenario
>
>
> > Rubbish,sorry Tony but that's what I think. You say
> experienced developers
> and big companies don't use "EQU INVNO.TABLE TO CUST(40)". I
> beg to differ.
> What do you call experienced? does 20 years count??? and what
> do you call a
> big company??? we only have two boxes running universe, two
> HP boxes, one
> with 32 processors and four logical machines, with over 5k
> users. We define
> all our files this way. Our user base is growing all the time
> as the company
> grows and our apps just keep on working.
> >
> > Les.
> >
> > -----Original Message-----
> > From: Tony Gravagno [mailto:[EMAIL PROTECTED]
> > Sent: 12 August 2005 07:23
> > To: [email protected]
> > Subject: [Maybe spam] RE: [U2] Remove Scenario
> >
> >
> > Mark Johnson wrote:
> > > Here's a doozy.
> >
> > Mark, the fundamental problem is that the original code
> wasn't designed
> for
> > the application that it's being asked to do now. That
> construct that you
> > describe "EQU INVNO.TABLE TO CUST(40)" is something that experienced
> > developers simply don't use anymore because it's such a bad
> idea. That
> > code was written for small companies and when they get
> larger it falls
> > apart as you see. It's like generating invoice numbers like this:
> > INV.NUM = (OLD.NUM+1)"R%4"
> > Anyone remember day 10,000?
> >
> >
> > This e-mail and any attachments are confidential and
> intended solely for
> the use of the addressee only. If you have received this
> message in error,
> you must not copy, distribute or disclose the contents;
> please notify the
> sender immediately and delete the message.
> > This message is attributed to the sender and may not
> necessarily reflect
> the view of Travis Perkins plc or its subsidiaries (Travis Perkins).
> Agreements binding Travis Perkins may not be concluded by
> means of e-mail
> communication.
> > E-mail transmissions are not secure and Travis Perkins accepts no
> responsibility for changes made to this message after it was
> sent. Whilst
> steps have been taken to ensure that this message is virus
> free, Travis
> Perkins accepts no liability for infection and recommends
> that you scan this
> e-mail and any attachments.
> > Part of Travis Perkins plc. Registered Office: Lodge Way
> House, Lodge Way,
> Harlestone Road, Northampton, NN5 7UG.
> > -------
> > 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/
