Re: [Maybe spam] RE: [U2] Remove Scenario
At 00:18 -0400 2005/08/13, Mark Johnson wrote: 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. I use constructs like this a lot and I'm new to MVDBMS (Started in '90). I know personally, I do this because of my Pascal/C/C++ background has me far, far too used to used to having real constants, enumerated types, variables that can be passed to subroutines by values or reference, etc. and EQUates are the best way to duplicate that functionality. As for using assignments instead of EQUates, I've seen far too often, insidious bugs that take much longer to track down than they should, because somebody accidentally/inadvertently changed a constant. I've seen this most often when a subroutine changes a passed in variable. This is very easy to do because all variables are passed by reference and not by value (the default in Pascal/C/C++). Ray -- .=. | =-=-=-=-=-=-= Eagle Rock Information Systems Corp =-=-=-=-=-=-= | | -=-=-=-=-=-=- web and database business solutions -=-=-=-=-=-=- | | http://www.eriscorp.commailto:[EMAIL PROTECTED] | |Midwest Regional Office: 815-547-0662 (voice) 815-547-0353 (Fax)| .=. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [Maybe spam] RE: [U2] Remove Scenario
On Fri, 2005-08-12 at 19:36 -0400, Mark Johnson wrote: 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 :) Jihad Yamout ( I think I 've got it spelled right) and his brother both worked on Primac in its early days. I'm not sure who was responsible for the cpylib system. I'll have to ask him tomorrow. I'm gonna have to bite the bullet and change my sig. At one time, before internationalisation and different character encodings, back when ASCII was king, it was a neat little ASCII art hack that looked like swirls of smoke and stars. It now seems that no one sees it as I send it, so I guess it's time to move on. Regards, -- Dave Walker The one absolutely unselfish friend that man can have in this selfish world, the one that never deserts him, the one that never proves ungrateful or treacherous, is his dog. -- George Graham Vest --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [Maybe spam] RE: [U2] Remove Scenario
In a message dated 8/12/2005 6:01:23 PM Pacific Daylight Time, [EMAIL PROTECTED] writes: If you're walking through and you see a CUSTdotwhatever you *know* - or at least you *should* know, if you're at *that* level - that CUSTdotwhatever is, the CUSTomer record and whatever refers to a particular field. Ergo: In RAID, CUST(field)/ gives the required response.. No downsides just another* way.. The issue is not whether you know that it's the Customer file. The issue is what value does Cust(address) have right now? You can't ask RAID while in Raid. What you have to do in this scenario, is have a cheat sheet or use another session to look up the Cust dictionary to figure out where the Address field is *at* and then ask raid something like */Cust(5) Will Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [Maybe spam] RE: [U2] Remove Scenario
In a message dated 8/12/2005 4:33:50 PM Pacific Daylight Time, [EMAIL PROTECTED] writes: 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... I don't think anyone is championing the cause for localizing what are in effect global variables. Rather my point was since RAID does not like a variable like EQUATE CUST.ADDR TO CUST(10) no matter where it's defined. Wouldn't it be better, at least from the perspective of a RAID user to use a variable like EQUATE A.CUST.ADDR TO 10 and then reference the address by R.CUST(A.CUST.ADDR) = '' or equally R.CUSTA.CUST.ADDR = '' depending on whether you've created R.CUST as a DIM or DYN array. That was my point, it has nothing to do with whether these definitions are done locally within the mainline program, or as an INCLUDE. Will Johnson Fast Foward Technologies --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
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: u2-users@listserver.u2ug.org 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 u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [Maybe spam] RE: [U2] Remove Scenario
I wasn't clear about that at all, sorry. What I meant was that experienced developers don't put a table of 50,000 invoice numbers into a single attribute in the customer master file, or even reserve one atb for open invoices and another one for closed, especially when either one of those atb's can expend beyond a couple thousand values. Equating a name to a dimensioned array element is absolutely standard and IMO preferred practice - sorry if that was confused. Tony Les Hewkin wrote: 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 That construct that you describe EQU INVNO.TABLE TO CUST(40) is something that experienced developers simply don't use anymore... --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [Maybe spam] RE: [U2] Remove Scenario
Tony, 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. I always value your responses, since you where the head guy at Pick Systems RD. Keep writing to this list. thanks. At 02:34 AM 8/12/2005 -0700, you wrote: I wasn't clear about that at all, sorry. What I meant was that experienced developers don't put a table of 50,000 invoice numbers into a single attribute in the customer master file, or even reserve one atb for open invoices and another one for closed, especially when either one of those atb's can expend beyond a couple thousand values. Equating a name to a dimensioned array element is absolutely standard and IMO preferred practice - sorry if that was confused. Tony Les Hewkin wrote: 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 That construct that you describe EQU INVNO.TABLE TO CUST(40) is something that experienced developers simply don't use anymore... --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
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.RECA.CUST.ADDRESS = Then RAID is quite happy with it. Will Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
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.NAMETOCUST.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: u2-users@listserver.u2ug.org 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: u2-users@listserver.u2ug.org 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 u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
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: u2-users@listserver.u2ug.org 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.RECA.CUST.ADDRESS = Then RAID is quite happy with it. Will Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [Maybe spam] RE: [U2] Remove Scenario
Sidebar. I wanted to change a 6 digit date value when re-processing a data set. The program would use today's date and I wanted to use the week prior. So I ran the program in the debugger and when I got to that line I did */DTE = 081005 of which I replaced it with 080305. and continued. When it was done, it had posted it to date 80305. Fortunately it isn't a date value just a posting reference. Thus, the debugger removed the leading zero (aka MS Excel Zip Codes). This was on D3. Is this also on UV/UD? Thanks. Mark Johnson P.S. Don't flame me for my method. Just focus on the debugger issue at hand. Thanks. - Original Message - From: [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org 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.RECA.CUST.ADDRESS = Then RAID is quite happy with it. Will Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
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: u2-users@listserver.u2ug.org 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: u2-users@listserver.u2ug.org 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.RECA.CUST.ADDRESS = Then RAID is quite happy with it. Will Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
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: u2-users@listserver.u2ug.org 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.NAMETOCUST.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: u2-users@listserver.u2ug.org 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: u2-users@listserver.u2ug.org 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 u2-users@listserver.u2ug.org To unsubscribe
Re: [Maybe spam] RE: [U2] Remove Scenario
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: u2-users@listserver.u2ug.org 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: u2-users@listserver.u2ug.org 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.NAMETOCUST.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: u2-users@listserver.u2ug.org 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: u2-users@listserver.u2ug.org 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
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: u2-users@listserver.u2ug.org 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 CUSTRECCUSTNAMEL#30: :CUSTREC49D2/ 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: u2-users@listserver.u2ug.org 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: u2-users@listserver.u2ug.org 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: u2-users@listserver.u2ug.org 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.RECA.CUST.ADDRESS = Then RAID is quite happy with it. Will Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [Maybe spam] RE: [U2] Remove Scenario
Goo'day, Will At 13:27 12/08/05 -0400, you wrote: 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. Ah yes, but If you're walking through and you see a CUSTdotwhatever you *know* - or at least you *should* know, if you're at *that* level - that CUSTdotwhatever is, the CUSTomer record and whatever refers to a particular field. Ergo: In RAID, CUST(field)/ gives the required response.. No downsides just another* way.. So is there a downside to using a construct like A.CUST.ADDRESS = 40 CUST.RECA.CUST.ADDRESS = Then RAID is quite happy with it. Will Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.338 / Virus Database: 267.10.8/71 - Release Date: 12/08/05 -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.338 / Virus Database: 267.10.8/71 - Release Date: 12/08/05 Regards, Bruce Nichol Talon Computer Services ALBURYNSW 2640 Australia http://www.taloncs.com.au Tel: +61 (0)411149636 Fax: +61 (0)260232119 If it ain't broke, fix it till it is! -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.338 / Virus Database: 267.10.8/71 - Release Date: 12/08/05 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [Maybe spam] RE: [U2] Remove Scenario
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 CUSTREC1 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: u2-users@listserver.u2ug.org 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: u2-users@listserver.u2ug.org 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
