I don't specifically recall the guy's name but it's from India or Pakistan or some hindu country. It's not Chandru Murthi though.
Thank him for me for making that part of my client's system more consistent than the other half. It's a hybrid of Primac for A/R, G/L, A/P & P/O with RESULTS running the Inventory, Order Entry, Sales Analysis. The Primac Job Costing Module is held in a very high regard and my client sorely misses it when they converted to Great Pains and got a rather childish replacement from GP. Thanks. P.S What's that stuff after your name. Looks like a foreign phone number or some computer graphics :) ----- Original Message ----- From: "Dave Walker" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, August 12, 2005 3:03 PM Subject: RE: [Maybe spam] RE: [U2] Remove Scenario > 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/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
