RE: [U2] RE: Cleaner Case Statement
Come on guys 'IF X ELSE blah' - is it really that bad/hard - it is logic and we are computer programmers, we should be able to figure out a lot tougher stuff than that ;) Rgds Symeon. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming Sent: 03 August 2007 01:32 To: u2-users@listserver.u2ug.org Subject: Re: [U2] RE: Cleaner Case Statement Then you must have the luzury of programming from scratch. I support roughly 15 clients worth of software written in various platforms with some source code stretching as far back as 1974. Yes, 33 year old code. I certainly program from scratch as well. But the incredibly large installed base uses IF X=1 THEN GOSUB 100 instead of the ALL_OK=X=1 then IF ALL_OK THEN DO_SOMETHING Again, don't read into the literal nature of the example. The deviated topic was avoiding the ELSE as the first condition in IF X=100 ELSE GOSUB 100 which is historically inconsistent. My 1 cent Mark Johnson - Original Message - From: Jeff Flynt [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, July 31, 2007 10:14 PM Subject: RE: [U2] RE: Cleaner Case Statement I typically use the full form of each structured statement and lay it out in the indented format. This is just coding laziness since I hate having to go back and add that missing branch of an if statement when I am 500 lines of code into it and several indent levels deep. This includes using the default branch of a case - the old fashioned CASE 1 clause. How I do it differently is in the wording. I like my code to be self documenting and consistent. Using a variable such as X and a label such as 100 is definitely a little dated. I used to, in the old days, create an equate for TRUE and set it to 1 = 1. And I would equate OTHERWISE to TRUE. I then have a CASE OTHERWISE, and I always have a CASE OTHERWISE on every case statement - even if it had no action. These days, I get lazy and just use CASE @TRUE since it would be an arrogant assumption of me to assume that 1 is true. At best it is very old school and poor form. But having the CASE @TRUE branch there is my signature; Coding every structured path is my style. On the other hand, while I don't do this a lot, I don't have any problem with the using the form IF X = 1 ELSE GOSUB 100 type statement. I do think it is dreadfully cryptic. I seriously hate dealing with this kind of code. What is X? What is 100? YIKES! And I like to avoid single use subroutines/GOSUBs when possible - not because they are inherently bad, but because they are parameterless and if you use it once why complicate the issue? I usually just put the code inline, but I occasionally don't if it would improve the self documenting nature of the code. Anyway, if X were a status code say, and we wanted to watch for a status of 1 I might do something like this: ALL_IS_WELL_PROCEED = X = 1 ; * This X business is just to match the previous example. ... Some code goes here including possibly status code ALL_IS_WELL_PROCEED updates ... IF ALL_IS_WELL_PROCEED ELSE GOSUB HANDLE_PROBLEM To me that reads like instructions to bake a cake, and anybody can see the intension. I do not have to have a degree in cryptography to read this regardless of how I set it up. It is 1,000,000 times easier to read then the suggested alternative IF X#1 THEN GOSUB 100 or IF X=1 ELSE GOSUB 100. Both are equally despicable. Either way the code is so obfuscated it is to be avoided at all cost! So why argue about how many angels can dance on the head of a pin when you cannot see the mountains in your molehills? It's like, is it better to pick you nose in public with your right hand or your left hand...? So, while I jest about this, I do have an ounce of seriousness about it. Everybody is so my way is better... And it just isn't. I include my own style in this. My way is only better if you like it better. Flatter whomever you like. Copy them! And deal with the god awful code that is out there... This thread should be closed. PS: I wonder if I am the horrible guy who coded the nested OPEN statements. I did do that once upon a time, long ago when I was a MADIC programmer. I was really hard core then. I don't do that anymore, but only because I am lazy. And I still don't have a problem with it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming Sent: Friday, July 27, 2007 9:09 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] RE: Cleaner Case Statement I think that CASE 1;Null is an old technique. If the prior conditions don't prevail, then don't bother. Otherwise every IF statement with a THEN would have ELSE NULL. BTW, using IF X = 1 ELSE GOSUB 100 is also very hard to read. Sure it compiles but source code should be readable for the programmers who have to visually interpet these things. EVERY IF should have an THEN as it's
Re: [U2] RE: Cleaner Case Statement
The code should be easy to understand. Yes. we can figure out a lot of stuff but if making the next guy to stumble over each line having to figure it out is not very professional. - Original Message - From: Symeon Breen [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, August 03, 2007 7:44 AM Subject: RE: [U2] RE: Cleaner Case Statement Come on guys 'IF X ELSE blah' - is it really that bad/hard - it is logic and we are computer programmers, we should be able to figure out a lot tougher stuff than that ;) Rgds Symeon. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming Sent: 03 August 2007 01:32 To: u2-users@listserver.u2ug.org Subject: Re: [U2] RE: Cleaner Case Statement Then you must have the luzury of programming from scratch. I support roughly 15 clients worth of software written in various platforms with some source code stretching as far back as 1974. Yes, 33 year old code. I certainly program from scratch as well. But the incredibly large installed base uses IF X=1 THEN GOSUB 100 instead of the ALL_OK=X=1 then IF ALL_OK THEN DO_SOMETHING Again, don't read into the literal nature of the example. The deviated topic was avoiding the ELSE as the first condition in IF X=100 ELSE GOSUB 100 which is historically inconsistent. My 1 cent Mark Johnson - Original Message - From: Jeff Flynt [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, July 31, 2007 10:14 PM Subject: RE: [U2] RE: Cleaner Case Statement I typically use the full form of each structured statement and lay it out in the indented format. This is just coding laziness since I hate having to go back and add that missing branch of an if statement when I am 500 lines of code into it and several indent levels deep. This includes using the default branch of a case - the old fashioned CASE 1 clause. How I do it differently is in the wording. I like my code to be self documenting and consistent. Using a variable such as X and a label such as 100 is definitely a little dated. I used to, in the old days, create an equate for TRUE and set it to 1 = 1. And I would equate OTHERWISE to TRUE. I then have a CASE OTHERWISE, and I always have a CASE OTHERWISE on every case statement - even if it had no action. These days, I get lazy and just use CASE @TRUE since it would be an arrogant assumption of me to assume that 1 is true. At best it is very old school and poor form. But having the CASE @TRUE branch there is my signature; Coding every structured path is my style. On the other hand, while I don't do this a lot, I don't have any problem with the using the form IF X = 1 ELSE GOSUB 100 type statement. I do think it is dreadfully cryptic. I seriously hate dealing with this kind of code. What is X? What is 100? YIKES! And I like to avoid single use subroutines/GOSUBs when possible - not because they are inherently bad, but because they are parameterless and if you use it once why complicate the issue? I usually just put the code inline, but I occasionally don't if it would improve the self documenting nature of the code. Anyway, if X were a status code say, and we wanted to watch for a status of 1 I might do something like this: ALL_IS_WELL_PROCEED = X = 1 ; * This X business is just to match the previous example. ... Some code goes here including possibly status code ALL_IS_WELL_PROCEED updates ... IF ALL_IS_WELL_PROCEED ELSE GOSUB HANDLE_PROBLEM To me that reads like instructions to bake a cake, and anybody can see the intension. I do not have to have a degree in cryptography to read this regardless of how I set it up. It is 1,000,000 times easier to read then the suggested alternative IF X#1 THEN GOSUB 100 or IF X=1 ELSE GOSUB 100. Both are equally despicable. Either way the code is so obfuscated it is to be avoided at all cost! So why argue about how many angels can dance on the head of a pin when you cannot see the mountains in your molehills? It's like, is it better to pick you nose in public with your right hand or your left hand...? So, while I jest about this, I do have an ounce of seriousness about it. Everybody is so my way is better... And it just isn't. I include my own style in this. My way is only better if you like it better. Flatter whomever you like. Copy them! And deal with the god awful code that is out there... This thread should be closed. PS: I wonder if I am the horrible guy who coded the nested OPEN statements. I did do that once upon a time, long ago when I was a MADIC programmer. I was really hard core then. I don't do that anymore, but only because I am lazy. And I still don't have a problem with it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming Sent: Friday, July 27, 2007 9:09 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] RE: Cleaner Case Statement I think that CASE 1;Null is an old
RE: [U2] RE: Cleaner Case Statement
To really throw the cat amongst the pigeons ... :-) I recently started using the IF ... ELSE programming style precisely *because* I found it *easier* to understand! Depending on what X is, it can be a lot more comprehensible to write IF X is true ELSE Rather than IF NOT X THEN Especially if X is some complicated expression. I prefer to write X in whatever manner is most easily understood (and that does not include a gratuitous negate), then use THEN or ELSE as appropriate. Cheers, Wol -Original Message- From: SP [mailto:[EMAIL PROTECTED] Sent: 03 August 2007 09:03 To: u2-users@listserver.u2ug.org Subject: Re: [U2] RE: Cleaner Case Statement The code should be easy to understand. Yes. we can figure out a lot of stuff but if making the next guy to stumble over each line having to figure it out is not very professional. - Original Message - From: Symeon Breen [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, August 03, 2007 7:44 AM Subject: RE: [U2] RE: Cleaner Case Statement Come on guys 'IF X ELSE blah' - is it really that bad/hard - it is logic and we are computer programmers, we should be able to figure out a lot tougher stuff than that ;) Rgds Symeon. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming Sent: 03 August 2007 01:32 To: u2-users@listserver.u2ug.org Subject: Re: [U2] RE: Cleaner Case Statement Then you must have the luzury of programming from scratch. I support roughly 15 clients worth of software written in various platforms with some source code stretching as far back as 1974. Yes, 33 year old code. I certainly program from scratch as well. But the incredibly large installed base uses IF X=1 THEN GOSUB 100 instead of the ALL_OK=X=1 then IF ALL_OK THEN DO_SOMETHING Again, don't read into the literal nature of the example. The deviated topic was avoiding the ELSE as the first condition in IF X=100 ELSE GOSUB 100 which is historically inconsistent. My 1 cent Mark Johnson - Original Message - From: Jeff Flynt [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, July 31, 2007 10:14 PM Subject: RE: [U2] RE: Cleaner Case Statement I typically use the full form of each structured statement and lay it out in the indented format. This is just coding laziness since I hate having to go back and add that missing branch of an if statement when I am 500 lines of code into it and several indent levels deep. This includes using the default branch of a case - the old fashioned CASE 1 clause. How I do it differently is in the wording. I like my code to be self documenting and consistent. Using a variable such as X and a label such as 100 is definitely a little dated. I used to, in the old days, create an equate for TRUE and set it to 1 = 1. And I would equate OTHERWISE to TRUE. I then have a CASE OTHERWISE, and I always have a CASE OTHERWISE on every case statement - even if it had no action. These days, I get lazy and just use CASE @TRUE since it would be an arrogant assumption of me to assume that 1 is true. At best it is very old school and poor form. But having the CASE @TRUE branch there is my signature; Coding every structured path is my style. On the other hand, while I don't do this a lot, I don't have any problem with the using the form IF X = 1 ELSE GOSUB 100 type statement. I do think it is dreadfully cryptic. I seriously hate dealing with this kind of code. What is X? What is 100? YIKES! And I like to avoid single use subroutines/GOSUBs when possible - not because they are inherently bad, but because they are parameterless and if you use it once why complicate the issue? I usually just put the code inline, but I occasionally don't if it would improve the self documenting nature of the code. Anyway, if X were a status code say, and we wanted to watch for a status of 1 I might do something like this: ALL_IS_WELL_PROCEED = X = 1 ; * This X business is just to match the previous example. ... Some code goes here including possibly status code ALL_IS_WELL_PROCEED updates ... IF ALL_IS_WELL_PROCEED ELSE GOSUB HANDLE_PROBLEM To me that reads like instructions to bake a cake, and anybody can see the intension. I do not have to have a degree in cryptography to read this regardless of how I set it up. It is 1,000,000 times easier to read then the suggested alternative IF X#1 THEN GOSUB 100 or IF X=1 ELSE GOSUB 100. Both are equally despicable. Either way the code is so obfuscated it is to be avoided at all cost! So why argue about how many angels can dance on the head of a pin when you cannot see the mountains in your molehills? It's like, is it better to pick you nose in public with your right hand or your left hand...? So, while I jest about this, I do have an ounce of seriousness about it. Everybody is so my way is better... And it just isn't. I include my
RES: [U2] Why MultiValue Associations ?
Using Universe, how do I inform that a dictionary item is a subvalue (multisubvalue) associated to another multivalue item? I am have problems to represent this scenario using ODBC/SQL The multivalues dictionary items works fine, since we put the controlling/dependent informations (C;n;n / D;n) on field 4 (type A dictionary)But until now I did not achieve with subvalue associations... Thanks in advance -Mensagem original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em nome de Kevin King Enviada em: quinta-feira, 2 de agosto de 2007 15:09 Para: u2-users@listserver.u2ug.org Assunto: Re: [U2] Why MultiValue Associations ? On 8/2/07, Brutzman, Bill [EMAIL PROTECTED] wrote: What are the advantages of defining in the data dictionary mv associations? In Unidata and Universe associations are crucial for associating multivalues when using BY-EXP. -Kevin http://www.PrecisOnline.com --- 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: [U2] Why MultiValue Associations ?
Just put a moniker in field 7 of the D-Descriptor of both dictionary items. --Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Marcos Fogaga Sent: Friday, August 03, 2007 6:45 AM To: u2-users@listserver.u2ug.org Subject: RES: [U2] Why MultiValue Associations ? Using Universe, how do I inform that a dictionary item is a subvalue (multisubvalue) associated to another multivalue item? I am have problems to represent this scenario using ODBC/SQL The multivalues dictionary items works fine, since we put the controlling/dependent informations (C;n;n / D;n) on field 4 (type A dictionary)But until now I did not achieve with subvalue associations... Thanks in advance -Mensagem original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em nome de Kevin King Enviada em: quinta-feira, 2 de agosto de 2007 15:09 Para: u2-users@listserver.u2ug.org Assunto: Re: [U2] Why MultiValue Associations ? On 8/2/07, Brutzman, Bill [EMAIL PROTECTED] wrote: What are the advantages of defining in the data dictionary mv associations? In Unidata and Universe associations are crucial for associating multivalues when using BY-EXP. -Kevin http://www.PrecisOnline.com --- 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: [U2] EXECUTE environment in Universe
Hi Dave, Try PERFORM, or convert subsequent actions to DATA statements prior to your first EXECUTE. Check the Universe Basic Reference Manual for the differences between PERFORM and EXECUTE. hth, Dave Dave Taylor CEO Sysmark Information Systems, Inc. 49 Aspen Way Rolling Hills Estates, CA 90274 800-SYSMARK (800-797-6275) (O) 310-544-1974 (C) 310-561-5200 (F) 310-377-3550 www.sysmarkinfo.com Your Source for Integrated EDI Translation, DataSync Integration and Software Migration Authorized IBM Business Partner - Original Message - From: Dave Greer [EMAIL PROTECTED] To: U2-Users (E-mail) u2-users@listserver.u2ug.org Sent: Friday, August 03, 2007 5:40 AM Subject: [U2] EXECUTE environment in Universe Is there a configuration setting or $OPTIONS routine, other than $OPTIONS PIOPEN.EXECUTE, that keeps select lists active when an Execute command is run? Our software package uses basic programs with execute statements rather than procs to run reports. An example might be something like the following: EXECUTE 'SSELECT ORDER WITH B/O.FLAG Y BY CUSTOMER BY DUE.DATE' CAPTURING REPLY RETURNING MSG IF SYSTEM(11) = 1 THEN EXECUTE 'PRINT BACKORDER.REPORT' END I'm afraid of the unintended consequences of using PIOPEN.EXECUTE because EXECUTES are used throughout hundreds of programs and many include named common variables. _ Dave Greer Director of Information Systems NewAge Industries AdvantaPure http://www.newageindustries.com/images/nalogo.jpg NewAge Industries, Inc. [EMAIL PROTECTED] www.newageindustries.com http://www.newageindustries.com/ 215.526.2300 PHONE 215.526.2191 FAX http://www.newageindustries.com/ Notice: If you are not the named recipient of this transmission, please notify us immediately, by telephone, and delete or destroy any copy of this message. You should not disclose or use this information in any way. Disclosure or use of this information may expose you to criminal or civil liabilities. We apologize for the inconvenience and thank you for your attention to this notice. --- 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: RES: [U2] Why MultiValue Associations ?
Unless something has been implemented since I last worked with Universe ODBC a couple years ago it will not correctly represent subvalues. It will represent associated multivalued fields as subtables but it is incapable of going past that level. Marcos Fogaga wrote: Using Universe, how do I inform that a dictionary item is a subvalue (multisubvalue) associated to another multivalue item? I am have problems to represent this scenario using ODBC/SQL The multivalues dictionary items works fine, since we put the controlling/dependent informations (C;n;n / D;n) on field 4 (type A dictionary)But until now I did not achieve with subvalue associations... Thanks in advance -Mensagem original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em nome de Kevin King Enviada em: quinta-feira, 2 de agosto de 2007 15:09 Para: u2-users@listserver.u2ug.org Assunto: Re: [U2] Why MultiValue Associations ? On 8/2/07, Brutzman, Bill [EMAIL PROTECTED] wrote: What are the advantages of defining in the data dictionary mv associations? In Unidata and Universe associations are crucial for associating multivalues when using BY-EXP. -Kevin http://www.PrecisOnline.com --- 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/ -- Jeff Schasny - Denver, Co, USA jeff at schasny dot com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] EXECUTE environment in Universe
I always use CLEARSELECT ALL before any EXECUTE SELECT... Without the CLEARSELECT ALL, strange things sometimes happen... like some other local user's program ran a SELECT and their SELECT results are still in memory. --Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dave Greer Sent: Friday, August 03, 2007 9:41 AM To: U2-Users (E-mail) Subject: [U2] EXECUTE environment in Universe Is there a configuration setting or $OPTIONS routine, other than $OPTIONS PIOPEN.EXECUTE, that keeps select lists active when an Execute command is run? Our software package uses basic programs with execute statements rather than procs to run reports. An example might be something like the following: EXECUTE 'SSELECT ORDER WITH B/O.FLAG Y BY CUSTOMER BY DUE.DATE' CAPTURING REPLY RETURNING MSG IF SYSTEM(11) = 1 THEN EXECUTE 'PRINT BACKORDER.REPORT' END I'm afraid of the unintended consequences of using PIOPEN.EXECUTE because EXECUTES are used throughout hundreds of programs and many include named common variables. _ Dave Greer Director of Information Systems NewAge Industries AdvantaPure http://www.newageindustries.com/images/nalogo.jpg NewAge Industries, Inc. [EMAIL PROTECTED] www.newageindustries.com http://www.newageindustries.com/ 215.526.2300 PHONE 215.526.2191 FAX http://www.newageindustries.com/ Notice: If you are not the named recipient of this transmission, please notify us immediately, by telephone, and delete or destroy any copy of this message. You should not disclose or use this information in any way. Disclosure or use of this information may expose you to criminal or civil liabilities. We apologize for the inconvenience and thank you for your attention to this notice. --- 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: [U2] Why MultiValue Associations ?
Hi Marcos, Using Universe, how do I inform that a dictionary item is a subvalue (multisubvalue) associated to another multivalue item? Unlike Unidata, UniVerse does not distinguish between items associated at the value level or those associated at the subvalue level. It should pair up things correctly (though I do vaguely recall that there may be a bug if the items wrap around to a new line). Martin Phillips Ladybridge Systems Ltd 17b Coldstream Lane, Hardingstone, Northampton, NN4 6DB +44-(0)1604-709200 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] EXECUTE environment in Universe
Seeing as you don't say whether you're wanting to enable PIOPEN.EXECUTE as a global option, or just in programs as you need to recompile them, it's not clear what exactly your problem is. Two things ... 1. Look at using PERFORM instead of EXECUTE. I'm not sure of the difference, but I strongly suspect that PERFORM *always* does a PI-style execute. I think PERFORM stays in the calling program's exec level, while EXECUTE by default creates a new one. 2. Look at rewriting your code something like EXECPHRASE = PA :@FM: SELECT ... :@FM: PRINT BACKORDER.REPORT PERFORM EXECPHRASE That way, you're guaranteed stable behaviour of select lists, etc etc. But if you're porting code, it looks like you're relying on PI-style executes, so setting PIOPEN.EXECUTE is unlikely to be a problem. Cheers, Wol -Original Message- From: Dave Greer [mailto:[EMAIL PROTECTED] Sent: 03 August 2007 14:41 To: U2-Users (E-mail) Subject: [U2] EXECUTE environment in Universe Is there a configuration setting or $OPTIONS routine, other than $OPTIONS PIOPEN.EXECUTE, that keeps select lists active when an Execute command is run? Our software package uses basic programs with execute statements rather than procs to run reports. An example might be something like the following: EXECUTE 'SSELECT ORDER WITH B/O.FLAG Y BY CUSTOMER BY DUE.DATE' CAPTURING REPLY RETURNING MSG IF SYSTEM(11) = 1 THEN EXECUTE 'PRINT BACKORDER.REPORT' END I'm afraid of the unintended consequences of using PIOPEN.EXECUTE because EXECUTES are used throughout hundreds of programs and many include named common variables. _ Dave Greer Director of Information Systems NewAge Industries AdvantaPure http://www.newageindustries.com/images/nalogo.jpg NewAge Industries, Inc. [EMAIL PROTECTED] www.newageindustries.com http://www.newageindustries.com/ 215.526.2300 PHONE 215.526.2191 FAX http://www.newageindustries.com/ Notice: If you are not the named recipient of this transmission, please notify us immediately, by telephone, and delete or destroy any copy of this message. You should not disclose or use this information in any way. Disclosure or use of this information may expose you to criminal or civil liabilities. We apologize for the inconvenience and thank you for your attention to this notice. --- 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: [U2] EXECUTE environment in Universe
Wol, Thanks for the suggestion. The problem is the order of magnitude. I have 889 programs with at least one or more instances of this code to change. That's a fair amount of code to change and test. I don't want to enable PIOPEN.EXECUTE or use PERFORM universally because, depending on the program, we may have one or two instances of this select list type of code combined with a recursive executed program or a program that executes another program with named common variables so I do not want to share the workspace. If possible, I would certainly elect to permit select lists to be active in a new environment like the system I am porting from. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Anthony Youngman Sent: Friday, August 03, 2007 10:13 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] EXECUTE environment in Universe Seeing as you don't say whether you're wanting to enable PIOPEN.EXECUTE as a global option, or just in programs as you need to recompile them, it's not clear what exactly your problem is. Two things ... 1. Look at using PERFORM instead of EXECUTE. I'm not sure of the difference, but I strongly suspect that PERFORM *always* does a PI-style execute. I think PERFORM stays in the calling program's exec level, while EXECUTE by default creates a new one. 2. Look at rewriting your code something like EXECPHRASE = PA :@FM: SELECT ... :@FM: PRINT BACKORDER.REPORT PERFORM EXECPHRASE That way, you're guaranteed stable behaviour of select lists, etc etc. But if you're porting code, it looks like you're relying on PI-style executes, so setting PIOPEN.EXECUTE is unlikely to be a problem. Cheers, Wol -Original Message- From: Dave Greer [mailto:[EMAIL PROTECTED] Sent: 03 August 2007 14:41 To: U2-Users (E-mail) Subject: [U2] EXECUTE environment in Universe Is there a configuration setting or $OPTIONS routine, other than $OPTIONS PIOPEN.EXECUTE, that keeps select lists active when an Execute command is run? Our software package uses basic programs with execute statements rather than procs to run reports. An example might be something like the following: EXECUTE 'SSELECT ORDER WITH B/O.FLAG Y BY CUSTOMER BY DUE.DATE' CAPTURING REPLY RETURNING MSG IF SYSTEM(11) = 1 THEN EXECUTE 'PRINT BACKORDER.REPORT' END I'm afraid of the unintended consequences of using PIOPEN.EXECUTE because EXECUTES are used throughout hundreds of programs and many include named common variables. _ Dave Greer Director of Information Systems NewAge Industries AdvantaPure http://www.newageindustries.com/images/nalogo.jpg NewAge Industries, Inc. [EMAIL PROTECTED] www.newageindustries.com http://www.newageindustries.com/ 215.526.2300 PHONE 215.526.2191 FAX http://www.newageindustries.com/ Notice: If you are not the named recipient of this transmission, please notify us immediately, by telephone, and delete or destroy any copy of this message. You should not disclose or use this information in any way. Disclosure or use of this information may expose you to criminal or civil liabilities. We apologize for the inconvenience and thank you for your attention to this notice. --- 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] EXECUTE environment in Universe
Is there a configuration setting or $OPTIONS routine, other than $OPTIONS PIOPEN.EXECUTE, that keeps select lists active when an Execute command is run? Our software package uses basic programs with execute statements rather than procs to run reports. An example might be something like the following: EXECUTE 'SSELECT ORDER WITH B/O.FLAG Y BY CUSTOMER BY DUE.DATE' CAPTURING REPLY RETURNING MSG IF SYSTEM(11) = 1 THEN EXECUTE 'PRINT BACKORDER.REPORT' END I'm afraid of the unintended consequences of using PIOPEN.EXECUTE because EXECUTES are used throughout hundreds of programs and many include named common variables. _ Dave Greer Director of Information Systems NewAge Industries AdvantaPure http://www.newageindustries.com/images/nalogo.jpg NewAge Industries, Inc. [EMAIL PROTECTED] www.newageindustries.com http://www.newageindustries.com/ 215.526.2300 PHONE 215.526.2191 FAX http://www.newageindustries.com/ Notice: If you are not the named recipient of this transmission, please notify us immediately, by telephone, and delete or destroy any copy of this message. You should not disclose or use this information in any way. Disclosure or use of this information may expose you to criminal or civil liabilities. We apologize for the inconvenience and thank you for your attention to this notice. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] EXECUTE environment in Universe
Dave - Since you are porting from another environment (such as mvBase), have you looked at the options that you can set using UniAdmin. If you are using PICK flavor as your standard, you may want to set the LAYERSEL option to zero in the UV configuration options. See UniAdmin and the Administration manual for more info on this option. Ken At 10:05 AM 8/3/2007, you wrote: Wol, Thanks for the suggestion. The problem is the order of magnitude. I have 889 programs with at least one or more instances of this code to change. That's a fair amount of code to change and test. I don't want to enable PIOPEN.EXECUTE or use PERFORM universally because, depending on the program, we may have one or two instances of this select list type of code combined with a recursive executed program or a program that executes another program with named common variables so I do not want to share the workspace. If possible, I would certainly elect to permit select lists to be active in a new environment like the system I am porting from. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Anthony Youngman Sent: Friday, August 03, 2007 10:13 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] EXECUTE environment in Universe Seeing as you don't say whether you're wanting to enable PIOPEN.EXECUTE as a global option, or just in programs as you need to recompile them, it's not clear what exactly your problem is. Two things ... 1. Look at using PERFORM instead of EXECUTE. I'm not sure of the difference, but I strongly suspect that PERFORM *always* does a PI-style execute. I think PERFORM stays in the calling program's exec level, while EXECUTE by default creates a new one. 2. Look at rewriting your code something like EXECPHRASE = PA :@FM: SELECT ... :@FM: PRINT BACKORDER.REPORT PERFORM EXECPHRASE That way, you're guaranteed stable behaviour of select lists, etc etc. But if you're porting code, it looks like you're relying on PI-style executes, so setting PIOPEN.EXECUTE is unlikely to be a problem. Cheers, Wol -Original Message- From: Dave Greer [mailto:[EMAIL PROTECTED] Sent: 03 August 2007 14:41 To: U2-Users (E-mail) Subject: [U2] EXECUTE environment in Universe Is there a configuration setting or $OPTIONS routine, other than $OPTIONS PIOPEN.EXECUTE, that keeps select lists active when an Execute command is run? Our software package uses basic programs with execute statements rather than procs to run reports. An example might be something like the following: EXECUTE 'SSELECT ORDER WITH B/O.FLAG Y BY CUSTOMER BY DUE.DATE' CAPTURING REPLY RETURNING MSG IF SYSTEM(11) = 1 THEN EXECUTE 'PRINT BACKORDER.REPORT' END I'm afraid of the unintended consequences of using PIOPEN.EXECUTE because EXECUTES are used throughout hundreds of programs and many include named common variables. _ Dave Greer Director of Information Systems NewAge Industries AdvantaPure http://www.newageindustries.com/images/nalogo.jpg NewAge Industries, Inc. [EMAIL PROTECTED] www.newageindustries.com http://www.newageindustries.com/ 215.526.2300 PHONE 215.526.2191 FAX http://www.newageindustries.com/ Notice: If you are not the named recipient of this transmission, please notify us immediately, by telephone, and delete or destroy any copy of this message. You should not disclose or use this information in any way. Disclosure or use of this information may expose you to criminal or civil liabilities. We apologize for the inconvenience and thank you for your attention to this notice. --- 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: [U2] EXECUTE environment in Universe
Ken, Yes, I am using PICK flavor and have set the LAYERSEL option to the default - 0. The manual mentions a K Mode. I don't know what that is and can find no other reference to it in any of the documentation. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ken Hall Sent: Friday, August 03, 2007 1:45 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] EXECUTE environment in Universe Dave - Since you are porting from another environment (such as mvBase), have you looked at the options that you can set using UniAdmin. If you are using PICK flavor as your standard, you may want to set the LAYERSEL option to zero in the UV configuration options. See UniAdmin and the Administration manual for more info on this option. Ken At 10:05 AM 8/3/2007, you wrote: Wol, Thanks for the suggestion. The problem is the order of magnitude. I have 889 programs with at least one or more instances of this code to change. That's a fair amount of code to change and test. I don't want to enable PIOPEN.EXECUTE or use PERFORM universally because, depending on the program, we may have one or two instances of this select list type of code combined with a recursive executed program or a program that executes another program with named common variables so I do not want to share the workspace. If possible, I would certainly elect to permit select lists to be active in a new environment like the system I am porting from. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Anthony Youngman Sent: Friday, August 03, 2007 10:13 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] EXECUTE environment in Universe Seeing as you don't say whether you're wanting to enable PIOPEN.EXECUTE as a global option, or just in programs as you need to recompile them, it's not clear what exactly your problem is. Two things ... 1. Look at using PERFORM instead of EXECUTE. I'm not sure of the difference, but I strongly suspect that PERFORM *always* does a PI-style execute. I think PERFORM stays in the calling program's exec level, while EXECUTE by default creates a new one. 2. Look at rewriting your code something like EXECPHRASE = PA :@FM: SELECT ... :@FM: PRINT BACKORDER.REPORT PERFORM EXECPHRASE That way, you're guaranteed stable behaviour of select lists, etc etc. But if you're porting code, it looks like you're relying on PI-style executes, so setting PIOPEN.EXECUTE is unlikely to be a problem. Cheers, Wol -Original Message- From: Dave Greer [mailto:[EMAIL PROTECTED] Sent: 03 August 2007 14:41 To: U2-Users (E-mail) Subject: [U2] EXECUTE environment in Universe Is there a configuration setting or $OPTIONS routine, other than $OPTIONS PIOPEN.EXECUTE, that keeps select lists active when an Execute command is run? Our software package uses basic programs with execute statements rather than procs to run reports. An example might be something like the following: EXECUTE 'SSELECT ORDER WITH B/O.FLAG Y BY CUSTOMER BY DUE.DATE' CAPTURING REPLY RETURNING MSG IF SYSTEM(11) = 1 THEN EXECUTE 'PRINT BACKORDER.REPORT' END I'm afraid of the unintended consequences of using PIOPEN.EXECUTE because EXECUTES are used throughout hundreds of programs and many include named common variables. _ Dave Greer Director of Information Systems NewAge Industries AdvantaPure http://www.newageindustries.com/images/nalogo.jpg NewAge Industries, Inc. [EMAIL PROTECTED] www.newageindustries.com http://www.newageindustries.com/ 215.526.2300 PHONE 215.526.2191 FAX http://www.newageindustries.com/ Notice: If you are not the named recipient of this transmission, please notify us immediately, by telephone, and delete or destroy any copy of this message. You should not disclose or use this information in any way. Disclosure or use of this information may expose you to criminal or civil liabilities. We apologize for the inconvenience and thank you for your attention to this notice. --- 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: [U2] RE: Cleaner Case Statement
personaly i find 'if x else' or if y then else just as easy to understand. if you stumble over such simple constructs then you are not a professional . sorry if that sound harsh, but it is my 2pennies... rgds Symeon On 03/08/07, SP [EMAIL PROTECTED] wrote: The code should be easy to understand. Yes. we can figure out a lot of stuff but if making the next guy to stumble over each line having to figure it out is not very professional. - Original Message - From: Symeon Breen [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, August 03, 2007 7:44 AM Subject: RE: [U2] RE: Cleaner Case Statement Come on guys 'IF X ELSE blah' - is it really that bad/hard - it is logic and we are computer programmers, we should be able to figure out a lot tougher stuff than that ;) Rgds Symeon. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming Sent: 03 August 2007 01:32 To: u2-users@listserver.u2ug.org Subject: Re: [U2] RE: Cleaner Case Statement Then you must have the luzury of programming from scratch. I support roughly 15 clients worth of software written in various platforms with some source code stretching as far back as 1974. Yes, 33 year old code. I certainly program from scratch as well. But the incredibly large installed base uses IF X=1 THEN GOSUB 100 instead of the ALL_OK=X=1 then IF ALL_OK THEN DO_SOMETHING Again, don't read into the literal nature of the example. The deviated topic was avoiding the ELSE as the first condition in IF X=100 ELSE GOSUB 100 which is historically inconsistent. My 1 cent Mark Johnson - Original Message - From: Jeff Flynt [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, July 31, 2007 10:14 PM Subject: RE: [U2] RE: Cleaner Case Statement I typically use the full form of each structured statement and lay it out in the indented format. This is just coding laziness since I hate having to go back and add that missing branch of an if statement when I am 500 lines of code into it and several indent levels deep. This includes using the default branch of a case - the old fashioned CASE 1 clause. How I do it differently is in the wording. I like my code to be self documenting and consistent. Using a variable such as X and a label such as 100 is definitely a little dated. I used to, in the old days, create an equate for TRUE and set it to 1 = 1. And I would equate OTHERWISE to TRUE. I then have a CASE OTHERWISE, and I always have a CASE OTHERWISE on every case statement - even if it had no action. These days, I get lazy and just use CASE @TRUE since it would be an arrogant assumption of me to assume that 1 is true. At best it is very old school and poor form. But having the CASE @TRUE branch there is my signature; Coding every structured path is my style. On the other hand, while I don't do this a lot, I don't have any problem with the using the form IF X = 1 ELSE GOSUB 100 type statement. I do think it is dreadfully cryptic. I seriously hate dealing with this kind of code. What is X? What is 100? YIKES! And I like to avoid single use subroutines/GOSUBs when possible - not because they are inherently bad, but because they are parameterless and if you use it once why complicate the issue? I usually just put the code inline, but I occasionally don't if it would improve the self documenting nature of the code. Anyway, if X were a status code say, and we wanted to watch for a status of 1 I might do something like this: ALL_IS_WELL_PROCEED = X = 1 ; * This X business is just to match the previous example. ... Some code goes here including possibly status code ALL_IS_WELL_PROCEED updates ... IF ALL_IS_WELL_PROCEED ELSE GOSUB HANDLE_PROBLEM To me that reads like instructions to bake a cake, and anybody can see the intension. I do not have to have a degree in cryptography to read this regardless of how I set it up. It is 1,000,000 times easier to read then the suggested alternative IF X#1 THEN GOSUB 100 or IF X=1 ELSE GOSUB 100. Both are equally despicable. Either way the code is so obfuscated it is to be avoided at all cost! So why argue about how many angels can dance on the head of a pin when you cannot see the mountains in your molehills? It's like, is it better to pick you nose in public with your right hand or your left hand...? So, while I jest about this, I do have an ounce of seriousness about it. Everybody is so my way is better... And it just isn't. I include my own style in this. My way is only better if you like it better. Flatter whomever you like. Copy them! And deal with the god awful code that is out there... This thread should be closed. PS: I wonder if I am the horrible guy who coded the nested OPEN statements. I did do that once
[U2] Unidata 7.1 and ODBC
I'm trying to get unidata 7.1 setup for ODBC access. I've installed each of UniODBC, UniDK and VSG. When I attempt to access the UCI Config editor, I get: C:\IBM\UniDK\JRE2\jte\bin\classic name jvm The specified module does not exist. Of course 'jte' is a typo - it should be 'jre'. But I didn't set this up - it was built this way as shipped on the middleware from IBM. I have edited C:\IBM\UniDK\Config\uci.config directly addding our database definition, but was wondering if there's an easy fix for the above. I attempted a shortcut named 'jte' but that won't fly. -- Jeff Butera, Ph.D. Administrative Systems Hampshire College [EMAIL PROTECTED] 413-559-5556 Daddy - did you lose your mind? Catherine Butera --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] RE: Cleaner Case Statement
Alright, it really gets my goat when people start tossing around you're not professional nonsense. Early in my (10 year) programming career, I was fond of clever constructs like if x else As I have matured as a developer, however, I have realized that the hallmark of good code is maintainability, and one of the greatest keys to maintainability is readability. The if x else... construct is non-standard, and it just doesn't flow. Sure, I understand it, but I don't expect it, so it slows down my thought process. Saying if not(x) then... accomplishes the same thing in a standard, easily readable form. It is much closer to English language expression, and more in line with most people's thought processes. As such, it will not slow me down in the least. I will never have to look at it twice to make sure I'm reading it right. It will make sense the first time. Therefore, in my opinion, it is far superior. Remember, you're not coding for yourself. You're coding for everyone who has to read your code after you. Symeon Breen wrote: personaly i find 'if x else' or if y then else just as easy to understand. if you stumble over such simple constructs then you are not a professional . sorry if that sound harsh, but it is my 2pennies... rgds Symeon On 03/08/07, SP [EMAIL PROTECTED] wrote: The code should be easy to understand. Yes. we can figure out a lot of stuff but if making the next guy to stumble over each line having to figure it out is not very professional. - Original Message - From: Symeon Breen [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, August 03, 2007 7:44 AM Subject: RE: [U2] RE: Cleaner Case Statement Come on guys 'IF X ELSE blah' - is it really that bad/hard - it is logic and we are computer programmers, we should be able to figure out a lot tougher stuff than that ;) Rgds Symeon. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming Sent: 03 August 2007 01:32 To: u2-users@listserver.u2ug.org Subject: Re: [U2] RE: Cleaner Case Statement Then you must have the luzury of programming from scratch. I support roughly 15 clients worth of software written in various platforms with some source code stretching as far back as 1974. Yes, 33 year old code. I certainly program from scratch as well. But the incredibly large installed base uses IF X=1 THEN GOSUB 100 instead of the ALL_OK=X=1 then IF ALL_OK THEN DO_SOMETHING Again, don't read into the literal nature of the example. The deviated topic was avoiding the ELSE as the first condition in IF X=100 ELSE GOSUB 100 which is historically inconsistent. My 1 cent Mark Johnson - Original Message - From: Jeff Flynt [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, July 31, 2007 10:14 PM Subject: RE: [U2] RE: Cleaner Case Statement I typically use the full form of each structured statement and lay it out in the indented format. This is just coding laziness since I hate having to go back and add that missing branch of an if statement when I am 500 lines of code into it and several indent levels deep. This includes using the default branch of a case - the old fashioned CASE 1 clause. How I do it differently is in the wording. I like my code to be self documenting and consistent. Using a variable such as X and a label such as 100 is definitely a little dated. I used to, in the old days, create an equate for TRUE and set it to 1 = 1. And I would equate OTHERWISE to TRUE. I then have a CASE OTHERWISE, and I always have a CASE OTHERWISE on every case statement - even if it had no action. These days, I get lazy and just use CASE @TRUE since it would be an arrogant assumption of me to assume that 1 is true. At best it is very old school and poor form. But having the CASE @TRUE branch there is my signature; Coding every structured path is my style. On the other hand, while I don't do this a lot, I don't have any problem with the using the form IF X = 1 ELSE GOSUB 100 type statement. I do think it is dreadfully cryptic. I seriously hate dealing with this kind of code. What is X? What is 100? YIKES! And I like to avoid single use subroutines/GOSUBs when possible - not because they are inherently bad, but because they are parameterless and if you use it once why complicate the issue? I usually just put the code inline, but I occasionally don't if it would improve the self documenting nature of the code. Anyway, if X were a status code say, and we wanted to watch for a status of 1 I might do something like this: ALL_IS_WELL_PROCEED = X = 1 ; * This X business is just to match the previous example. ... Some code goes here including possibly status code ALL_IS_WELL_PROCEED updates ... IF ALL_IS_WELL_PROCEED ELSE GOSUB HANDLE_PROBLEM To me that reads like instructions to bake a cake,
RE: [U2] Unidata 7.1 and ODBC
What's your *system* (not user please) CLASSPATH environment variable set to? Regards JayJay --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] RE: Cleaner Case Statement
My point exactly. I've probably followed behind at least 50 mv programmers with all of my clients. I can detect a style and 'bracket' them into understanding the way they think. Factor in the time frame of their coding and their limitations come out pretty quickly. As I balance my 15 clients, I am often that programmer following myself, as I cannot remember every routine I've written for someone in the last 30 years. But recognizing easy-to-read code certainly helps get me back to speed. Thanks Mark Johnson - Original Message - From: Geoffrey Mitchell [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, August 03, 2007 4:42 PM Subject: Re: [U2] RE: Cleaner Case Statement Alright, it really gets my goat when people start tossing around you're not professional nonsense. Early in my (10 year) programming career, I was fond of clever constructs like if x else As I have matured as a developer, however, I have realized that the hallmark of good code is maintainability, and one of the greatest keys to maintainability is readability. The if x else... construct is non-standard, and it just doesn't flow. Sure, I understand it, but I don't expect it, so it slows down my thought process. Saying if not(x) then... accomplishes the same thing in a standard, easily readable form. It is much closer to English language expression, and more in line with most people's thought processes. As such, it will not slow me down in the least. I will never have to look at it twice to make sure I'm reading it right. It will make sense the first time. Therefore, in my opinion, it is far superior. Remember, you're not coding for yourself. You're coding for everyone who has to read your code after you. Symeon Breen wrote: personaly i find 'if x else' or if y then else just as easy to understand. if you stumble over such simple constructs then you are not a professional . sorry if that sound harsh, but it is my 2pennies... rgds Symeon On 03/08/07, SP [EMAIL PROTECTED] wrote: The code should be easy to understand. Yes. we can figure out a lot of stuff but if making the next guy to stumble over each line having to figure it out is not very professional. - Original Message - From: Symeon Breen [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, August 03, 2007 7:44 AM Subject: RE: [U2] RE: Cleaner Case Statement Come on guys 'IF X ELSE blah' - is it really that bad/hard - it is logic and we are computer programmers, we should be able to figure out a lot tougher stuff than that ;) Rgds Symeon. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming Sent: 03 August 2007 01:32 To: u2-users@listserver.u2ug.org Subject: Re: [U2] RE: Cleaner Case Statement Then you must have the luzury of programming from scratch. I support roughly 15 clients worth of software written in various platforms with some source code stretching as far back as 1974. Yes, 33 year old code. I certainly program from scratch as well. But the incredibly large installed base uses IF X=1 THEN GOSUB 100 instead of the ALL_OK=X=1 then IF ALL_OK THEN DO_SOMETHING Again, don't read into the literal nature of the example. The deviated topic was avoiding the ELSE as the first condition in IF X=100 ELSE GOSUB 100 which is historically inconsistent. My 1 cent Mark Johnson - Original Message - From: Jeff Flynt [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Tuesday, July 31, 2007 10:14 PM Subject: RE: [U2] RE: Cleaner Case Statement I typically use the full form of each structured statement and lay it out in the indented format. This is just coding laziness since I hate having to go back and add that missing branch of an if statement when I am 500 lines of code into it and several indent levels deep. This includes using the default branch of a case - the old fashioned CASE 1 clause. How I do it differently is in the wording. I like my code to be self documenting and consistent. Using a variable such as X and a label such as 100 is definitely a little dated. I used to, in the old days, create an equate for TRUE and set it to 1 = 1. And I would equate OTHERWISE to TRUE. I then have a CASE OTHERWISE, and I always have a CASE OTHERWISE on every case statement - even if it had no action. These days, I get lazy and just use CASE @TRUE since it would be an arrogant assumption of me to assume that 1 is true. At best it is very old school and poor form. But having the CASE @TRUE branch there is my signature; Coding every structured path is my style. On the other hand, while I don't do this a lot, I don't have any problem with the using the form IF X = 1 ELSE GOSUB 100 type statement. I do think it is dreadfully cryptic. I seriously hate dealing with this kind of code. What is X?
RE: [U2] Unidata 7.1 and ODBC
What's your *system* (not user please) CLASSPATH environment variable set to? Not set - what would you like it to be? Jeff Butera, Ph.D. Administrative Systems Hampshire College [EMAIL PROTECTED] 413-559-5556 Daddy - did you lose your mind? Catherine Butera --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
