Re: RE: [U2] OCONV Extraction Question - Good Practice
"Good" code. What (TF) is that and how does that relate to a statements inclusion in a manual or not? Explain yourself and - the rules for you are - don't peek in a dictionary or use an electronic grammar or spell checker. ;-) Stuart Boydell Hi Stuart. Ignoring all dictionary and thesaurus explanations available I have a simple definition of "good" code - is it efficient and can it be easily maintained by someone else? I appreciate that this is an arbitary and difficult to measure standard, but it's my standard nonetheless :-) We have a language that invariably allows a solution to be written in a number of different ways. If I was to work alongside - or worse, after - a programmer that utiilised obscure conversion codes that no-one else understood rather than a simpler to read line of code that did exactly the same thing then I wouldn't be very happy. While my original point was relating to the certification questions, the post from Keith this week where he changed the line of code into something much more readable is a classic example. We may not all agree with precisely how he's done it, but we can probably all see the reason why he did. The discussions about coding that have woken this list up in recent weeks show that there are lots of "standards" out there, but I think that there is probably one rule that's true to all of us - we all recognise bad code when we see it, even if it was us what wrote it! Colin. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: RE: [U2] OCONV Extraction Question - Good Practice
"Good" code. What (TF) is that and how does that relate to a statements inclusion in a manual or not? Explain yourself and - the rules for you are - don't peek in a dictionary or use an electronic grammar or spell checker. ;-) Stuart Boydell >-Original Message- >> Yeah - I remember thinking on some of those conversion questions that I >> did not really know what they did - when it comes to strange or complex >> conversions like that I just get the manual out. It is certainly not >> something one does every day. >Exactly the point I was making - if something you've written requires the >next person to get the manual out to understand it then it's not good code, >regardless of whether it's more efficient or not. Just because you *can* do >it doesn't mean you *should* do it! ** This email message and any files transmitted with it are confidential and intended solely for the use of addressed recipient(s). If you have received this communication in error, please reply to this e-mail to notify the sender of its incorrect delivery and then delete it and your reply. It is your responsibility to check this email and any attachments for viruses and defects before opening or sending them on. Spotless collects information about you to provide and market our services. For information about use, disclosure and access, see our privacy policy at http://www.spotless.com.au Please consider our environment before printing this email. ** --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: RE: [U2] OCONV Extraction Question - Good Practice
Surely getting the manual out to look up an obscure oconv is reasonable, and putting it in their not bad coding, it takes 20 seconds to look it up !! - I presume you guys donbt program in .net or java etc where looking up the help of some object you have never used before happens quite a lot - well there are thousands of them -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colin Jennings Sent: 26 November 2007 10:23 To: u2-users@listserver.u2ug.org Subject: Re: RE: [U2] OCONV Extraction Question - Good Practice > Yeah - I remember thinking on some of those conversion questions that I > did not really know what they did - when it comes to strange or complex > conversions like that I just get the manual out. It is certainly not > something one does every day. > > > Symeon. Exactly the point I was making - if something you've written requires the next person to get the manual out to understand it then it's not good code, regardless of whether it's more efficient or not. Just because you *can* do it doesn't mean you *should* do it! Col. --- 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: RE: [U2] OCONV Extraction Question - Good Practice
Yeah - I remember thinking on some of those conversion questions that I did not really know what they did - when it comes to strange or complex conversions like that I just get the manual out. It is certainly not something one does every day. Symeon. Exactly the point I was making - if something you've written requires the next person to get the manual out to understand it then it's not good code, regardless of whether it's more efficient or not. Just because you *can* do it doesn't mean you *should* do it! Col. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: RE: [U2] OCONV Extraction Question - Good Practice
Yeah - I remember thinking on some of those conversion questions that I did not really know what they did - when it comes to strange or complex conversions like that I just get the manual out. It is certainly not something one does every day. Symeon. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jerry Banker Sent: 23 November 2007 16:18 To: u2-users@listserver.u2ug.org Subject: RE: RE: [U2] OCONV Extraction Question - Good Practice I felt the same way with that part of the test. I have never seen a need for some of the conversion codes described because there is usually something less obscure and more descriptive (English like) that can be used. Now for some programmers the formats and conversions in the test may be used but I have worked for companies in manufacturing, education, banking, and accounting and some of the conversions in the test I would never and have never used. Jerry > -Original Message- > From: Colin Jennings [mailto:[EMAIL PROTECTED] > Sent: Friday, November 23, 2007 9:01 AM > To: u2-users@listserver.u2ug.org > Subject: Re: RE: [U2] OCONV Extraction Question - Good Practice > > > Go to http://www-03.ibm.com/certify/tests/test_index_bd.shtml#0 > > > > If you look down the page you will see the list of certifications IBM > > has available for U2, just under the Informix certifications, there are > > 6, 5 for UniData and UniVerse Administration and 1 for U2 Family > > Application Development. The certification testing was free if you > > attended one of the U2 Universities and took the tests there. > > > > > > Brenda Price > > > I did the exams at the recent U2U in London and I have to say that the > conversions contained in the Family Application Development test were some > of the worst examples of code I have ever seen. Obviously they're possible, > but I think I'd consider sacking any programmer that used them!! > > Colin. > (well and truly certified) > --- > 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: RE: [U2] OCONV Extraction Question - Good Practice
--- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: RE: [U2] OCONV Extraction Question - Good Practice
Go to http://www-03.ibm.com/certify/tests/test_index_bd.shtml#0 If you look down the page you will see the list of certifications IBM has available for U2, just under the Informix certifications, there are 6, 5 for UniData and UniVerse Administration and 1 for U2 Family Application Development. The certification testing was free if you attended one of the U2 Universities and took the tests there. Brenda Price I did the exams at the recent U2U in London and I have to say that the conversions contained in the Family Application Development test were some of the worst examples of code I have ever seen. Obviously they're possible, but I think I'd consider sacking any programmer that used them!! Colin. (well and truly certified) --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: RE: [U2] OCONV Extraction Question - Good Practice
I felt the same way with that part of the test. I have never seen a need for some of the conversion codes described because there is usually something less obscure and more descriptive (English like) that can be used. Now for some programmers the formats and conversions in the test may be used but I have worked for companies in manufacturing, education, banking, and accounting and some of the conversions in the test I would never and have never used. Jerry > -Original Message- > From: Colin Jennings [mailto:[EMAIL PROTECTED] > Sent: Friday, November 23, 2007 9:01 AM > To: u2-users@listserver.u2ug.org > Subject: Re: RE: [U2] OCONV Extraction Question - Good Practice > > > Go to http://www-03.ibm.com/certify/tests/test_index_bd.shtml#0 > > > > If you look down the page you will see the list of certifications IBM > > has available for U2, just under the Informix certifications, there are > > 6, 5 for UniData and UniVerse Administration and 1 for U2 Family > > Application Development. The certification testing was free if you > > attended one of the U2 Universities and took the tests there. > > > > > > Brenda Price > > > I did the exams at the recent U2U in London and I have to say that the > conversions contained in the Family Application Development test were some > of the worst examples of code I have ever seen. Obviously they're possible, > but I think I'd consider sacking any programmer that used them!! > > Colin. > (well and truly certified) > --- > 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] OCONV Extraction Question - Good Practice
Oh yeah, what "Certification" ? If any exists, I haven't stumbled upon it. Mark Johnson Go to http://www-03.ibm.com/certify/tests/test_index_bd.shtml#0 If you look down the page you will see the list of certifications IBM has available for U2, just under the Informix certifications, there are 6, 5 for UniData and UniVerse Administration and 1 for U2 Family Application Development. The certification testing was free if you attended one of the U2 Universities and took the tests there. Brenda Price --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] OCONV Extraction Question - Good Practice
IBM Certified Solutions Expert U2 Family Applications Development (passed it twice for good measure), IBM Certified Solutions Expert U2 UniVerse V9.6 Administrator for Unix and Windows, and IBM Certified Solutions Expert U2 UniVerse V10.1 Administrator. You can take the tests at the U2U or the conferences free of charge. Otherwise, I believe they are available at any time for a charge. Jerry > -Original Message- > From: MAJ Programming [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 21, 2007 11:49 PM > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] OCONV Extraction Question - Good Practice > > Considering the garbage I've inherited, I feel that I've made many previous > expressions more concise and direct. > > Oh yeah, what "Certification" ? If any exists, I haven't stumbled upon it. > > Mark Johnson --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] OCONV Extraction Question - Good Practice
That's what the compiler is for. After all, it has the final word on the sourse code and any 'pre-compilers'. I'm having a similar dialog with someone on the D3 forum about their insistence upon 'changing' the syntax of data/basic statements as he feels that their syntax is not 'natural'. So he spends a lot of time developing his own pre-compiler that allows his new expressions to work for him yet get converted to the eventual data/basic compiler. I'm glad that you recognize that you're in a closed shop and don't have to worry about outside considerations. Given the vast amount of $OPTIONS that can be set in U2 systems, then you can customize your environment to exactly the one you like and go from there. Your two examples are just that, examples. I'm not going to stand on a soapbox and imply that you don't test. Not at all. But this kind of stuff comes up in the testing cycle of the project and if unexpected results occur, as in your 2 examples, then the testing has done its job in identifying a problem. Has EVERY instance of my typing VAL/100"R2#10" been perfect. Of course not, just as every example of your typing FMT(OCONV didn't work every time either. Whether yours gets caught in a pre-compiler, the regular compiler or the testing cycle, it will eventually get caught and repaired. Being in a closed shop is almost a luxury. You have a forced 'style' (the word 'standard' is too global) that allows your entire application to maintain a cohesive feel, look and, most importantly, programmability and maintainability. That's a luxury that I don't have at any of my clients. Zero. I am the current cook in the kitchen and based on the styles and date stamps of prior programmers, I can detect an average of 5-6 different thought processes in the code that all come together for each client's application. There's no reverse-implying a single standard (sorry, 'style'). Many on this forum have this luxury. And I'm sure many do not. Thanks Mark Johnson ----- Original Message - From: "Womack, Adrian" <[EMAIL PROTECTED]> To: Sent: Thursday, November 22, 2007 1:56 AM Subject: RE: [U2] OCONV Extraction Question - Good Practice > Using FMT forces correct syntax use. Having the trailing formatting > characters, can cause all kinds of issues with small typos in the code > (especially when the compiler just takes it all in it's stride). > > Look at these two examples: > > * Accidentally inserting a space into a numeric constant > A = 123 4 > CRT A > * displays 123. > > * missing out a colon or a comma > CRT "XYZ" "ABC" > * Displays ABC > > We use a syntax checking program which throws both of these out as bad > syntax, so the code never gets anywhere near production. IMO the > compiler shouldn't accept this type of formatting (or perhaps there > should be a compiler $option). Although, we are a closed shop and work > exclusively in PI/Open flavour, so portability isn't an issue for us. > > AdrianW > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming > Sent: Thursday, 22 November 2007 2:54 PM > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] OCONV Extraction Question - Good Practice > > I gotta ask. How is it a disaster waiting to happen. > > This 'best practices' exercise may die an early death with such > unauthorized conclusions. How are you judging the CRT example as > 'disasterous'. > > Mark Johnson > > BTW, the FMT expression may not play well with other MV flavours. Thus, > I tend to program continouosly to cover all of my client's needs. > > > DISCLAIMER: > Disclaimer. This e-mail is private and confidential. If you are not the intended recipient, please advise us by return e-mail immediately, and delete the e-mail and any attachments without using or disclosing the contents in any way. The views expressed in this e-mail are those of the author, and do not represent those of this company unless this is clearly indicated. You should scan this e-mail and any attachments for viruses. This company accepts no liability for any direct or indirect damage or loss resulting from the use of any attachments to this e-mail. > --- > 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] OCONV Extraction Question - Good Practice
Using FMT forces correct syntax use. Having the trailing formatting characters, can cause all kinds of issues with small typos in the code (especially when the compiler just takes it all in it's stride). Look at these two examples: * Accidentally inserting a space into a numeric constant A = 123 4 CRT A * displays 123. * missing out a colon or a comma CRT "XYZ" "ABC" * Displays ABC We use a syntax checking program which throws both of these out as bad syntax, so the code never gets anywhere near production. IMO the compiler shouldn't accept this type of formatting (or perhaps there should be a compiler $option). Although, we are a closed shop and work exclusively in PI/Open flavour, so portability isn't an issue for us. AdrianW -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming Sent: Thursday, 22 November 2007 2:54 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] OCONV Extraction Question - Good Practice I gotta ask. How is it a disaster waiting to happen. This 'best practices' exercise may die an early death with such unauthorized conclusions. How are you judging the CRT example as 'disasterous'. Mark Johnson BTW, the FMT expression may not play well with other MV flavours. Thus, I tend to program continouosly to cover all of my client's needs. DISCLAIMER: Disclaimer. This e-mail is private and confidential. If you are not the intended recipient, please advise us by return e-mail immediately, and delete the e-mail and any attachments without using or disclosing the contents in any way. The views expressed in this e-mail are those of the author, and do not represent those of this company unless this is clearly indicated. You should scan this e-mail and any attachments for viruses. This company accepts no liability for any direct or indirect damage or loss resulting from the use of any attachments to this e-mail. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] OCONV Extraction Question - Good Practice
I gotta ask. How is it a disaster waiting to happen. This 'best practices' exercise may die an early death with such unauthorized conclusions. How are you judging the CRT example as 'disasterous'. Mark Johnson BTW, the FMT expression may not play well with other MV flavours. Thus, I tend to program continouosly to cover all of my client's needs. - Original Message - From: "Jeff Schasny" <[EMAIL PROTECTED]> To: Sent: Tuesday, November 20, 2007 11:32 AM Subject: Re: [U2] OCONV Extraction Question - Good Practice > I'm not as concerned about the old style format strings as I am about > the readability of the code and ease of future modification concerning > the printed (CRT'd in this case) string. I'd do this: > > OUT.LINE = FMT(OCONV(VAR1,"MD0"),"R#6 ") > OUT.LINE := FMT(OCONV(VAR2,"MD2"),"R#10") > OUT.LINE := FMT(OCONV(VAR3,"MD4"),"R#14") > CRT OUT.LINE > > > Womack, Adrian wrote: > > IMO, the only thing wrong with your example is the use of the trailing > > format strings - everyone (and I mean everyone) should be using the FMT > > function, making your example: > > > > CRT FMT(OCONV(VAR1,"MD0"),"R#6 "):FMT(OCONV(VAR2,"MD2"),"R#10 > > "):FMT(OCONV(VAR3,"MD4"),"R#14") > > > > The old method is a disaster waiting to happen. > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming > > Sent: Tuesday, 20 November 2007 2:12 PM > > To: u2-users@listserver.u2ug.org > > Subject: Re: [U2] OCONV Extraction Question - Good Practice > > > > Here begins the voting for differences. > > > > I actually do not care for the inclusion of the extra Var1.F variables > > as, mentioned earlier, is that variable used elsewhere? Plus, it implies > > that it maybe part of a calculation instead of an upcoming, disposable > > CRT statement. > > > > Will I rot as I use this CRT statement? > > > > CRT OCONV(VAR1,"MD0")"R#6':" ":OCONV(VAR2,"MD2")"R#10":" > > ":OCONV(VAR3,"MD4")"R#14". > > > > > > > > DISCLAIMER: > > Disclaimer. This e-mail is private and confidential. If you are not the intended recipient, please advise us by return e-mail immediately, and delete the e-mail and any attachments without using or disclosing the contents in any way. The views expressed in this e-mail are those of the author, and do not represent those of this company unless this is clearly indicated. You should scan this e-mail and any attachments for viruses. This company accepts no liability for any direct or indirect damage or loss resulting from the use of any attachments to this e-mail. > > --- > > 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/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] OCONV Extraction Question - Good Practice
Exactly why is CRT VAR1/100"R2#10" such a challenge to those who want to use CRT FMT(OCONV(VAR1,"MD2")"R2#10") ? I've concluded that method years ago and haven't looked back. Surely by now if there was some hidden problem I would have run into it by now. Mark Johnson - Original Message - From: "Susan Lynch" <[EMAIL PROTECTED]> To: Sent: Tuesday, November 20, 2007 3:56 PM Subject: Re: [U2] OCONV Extraction Question - Good Practice > Also, according to the UniBasic Reference Manual, "The FMT function can > produce different results based on the BASICTYPE setting." So, if we are > going to discuss programming standards, do we have to discuss them for each > BASICTYPE flavor? The manual documents what happens with BASICTYPE U, but > those of us who are in SB shops are required to use BASICTYPE P, where the > documentation does not often specify what the variations will be. > > Susan M. Lynch > F.W. Davison & Company, Inc. > > - Original Message - > From: "Bill Haskett" <[EMAIL PROTECTED]> > To: > Sent: Tuesday, November 20, 2007 3:14 PM > Subject: RE: [U2] OCONV Extraction Question - Good Practice > > > > Adrian: > > > > I'm not sure about the disaster part. We've moved from D3 to Unidata (a > > trying > > experience) and the string handling seems to work fine. We have code > > like: > > > > CRT OCONV(VAR1, 'MD0') "R(#06)" : > > CRT OCONV(VAR2, 'MD2') "R(#10)" : > > CRT OCONV(VAR3, 'MD4') "R(#14)" ; ** end of output line > > > > ...and it works perfectly. So, since FMT isn't (or at least hasn't been) > > as portable > > as the string formating code (FMT wasn't part of the Adds, GA, R83, > > AdvPick, D3 line > > of MV), I'd say using FMT violates the guideline of "make it portable". > > > > Just a thought... > > > > Bill > > > >>Womack, Adrian wrote: > >>> IMO, the only thing wrong with your example is the use of the trailing > >>> format strings - everyone (and I mean everyone) should be using the FMT > >>> function, making your example: > >>> > >>> CRT FMT(OCONV(VAR1,"MD0"),"R#6 "):FMT(OCONV(VAR2,"MD2"),"R#10 > >>> "):FMT(OCONV(VAR3,"MD4"),"R#14") > >>> > >>> The old method is a disaster waiting to happen. > >>> > >>> -Original Message- > >>> From: [EMAIL PROTECTED] > >>> [mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming > >>> Sent: Tuesday, 20 November 2007 2:12 PM > >>> To: u2-users@listserver.u2ug.org > >>> Subject: Re: [U2] OCONV Extraction Question - Good Practice > >>> > >>> Here begins the voting for differences. > >>> > >>> I actually do not care for the inclusion of the extra Var1.F variables > >>> as, mentioned earlier, is that variable used elsewhere? Plus, it implies > >>> that it maybe part of a calculation instead of an upcoming, disposable > >>> CRT statement. > >>> > >>> Will I rot as I use this CRT statement? > >>> > >>> CRT OCONV(VAR1,"MD0")"R#6':" ":OCONV(VAR2,"MD2")"R#10":" > >>> ":OCONV(VAR3,"MD4")"R#14". > > --- > > 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] OCONV Extraction Question - Good Practice
Considering the garbage I've inherited, I feel that I've made many previous expressions more concise and direct. Oh yeah, what "Certification" ? If any exists, I haven't stumbled upon it. Mark Johnson - Original Message - From: "Jerry Banker" <[EMAIL PROTECTED]> To: Sent: Tuesday, November 20, 2007 10:00 AM Subject: RE: [U2] OCONV Extraction Question - Good Practice > I don't like it. I've been in the language for over 25 years and have > passed the certification a couple of times and when I looked at this I > was scratching my head for a while. Obviously you know what you are > doing but what is going to happen with the next programmer when you > retire. > > -Original Message- > From: MAJ Programming [mailto:[EMAIL PROTECTED] > Sent: Monday, November 19, 2007 11:12 PM > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] OCONV Extraction Question - Good Practice > > Oddly enough, to make things more interesting, I would have coded it > this > way: > > CRT VAR1"R0#6":" ":VAR2/100"R2#10":" ":VAR3/1"R4#14" > > Less typing. For output, the only time I use OCONV is a "MTx" time > conversion or if the value isn't justified and I want the all the > decimals. > I use DATE()"D2/" beaucoups of times. > --- > 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] OCONV Extraction Question - Good Practice
Also, according to the UniBasic Reference Manual, "The FMT function can produce different results based on the BASICTYPE setting." So, if we are going to discuss programming standards, do we have to discuss them for each BASICTYPE flavor? The manual documents what happens with BASICTYPE U, but those of us who are in SB shops are required to use BASICTYPE P, where the documentation does not often specify what the variations will be. Susan M. Lynch F.W. Davison & Company, Inc. - Original Message - From: "Bill Haskett" <[EMAIL PROTECTED]> To: Sent: Tuesday, November 20, 2007 3:14 PM Subject: RE: [U2] OCONV Extraction Question - Good Practice Adrian: I'm not sure about the disaster part. We've moved from D3 to Unidata (a trying experience) and the string handling seems to work fine. We have code like: CRT OCONV(VAR1, 'MD0') "R(#06)" : CRT OCONV(VAR2, 'MD2') "R(#10)" : CRT OCONV(VAR3, 'MD4') "R(#14)" ; ** end of output line ...and it works perfectly. So, since FMT isn't (or at least hasn't been) as portable as the string formating code (FMT wasn't part of the Adds, GA, R83, AdvPick, D3 line of MV), I'd say using FMT violates the guideline of "make it portable". Just a thought... Bill Womack, Adrian wrote: IMO, the only thing wrong with your example is the use of the trailing format strings - everyone (and I mean everyone) should be using the FMT function, making your example: CRT FMT(OCONV(VAR1,"MD0"),"R#6 "):FMT(OCONV(VAR2,"MD2"),"R#10 "):FMT(OCONV(VAR3,"MD4"),"R#14") The old method is a disaster waiting to happen. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming Sent: Tuesday, 20 November 2007 2:12 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] OCONV Extraction Question - Good Practice Here begins the voting for differences. I actually do not care for the inclusion of the extra Var1.F variables as, mentioned earlier, is that variable used elsewhere? Plus, it implies that it maybe part of a calculation instead of an upcoming, disposable CRT statement. Will I rot as I use this CRT statement? CRT OCONV(VAR1,"MD0")"R#6':" ":OCONV(VAR2,"MD2")"R#10":" ":OCONV(VAR3,"MD4")"R#14". --- 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] OCONV Extraction Question - Good Practice
Adrian: I'm not sure about the disaster part. We've moved from D3 to Unidata (a trying experience) and the string handling seems to work fine. We have code like: CRT OCONV(VAR1, 'MD0') "R(#06)" : CRT OCONV(VAR2, 'MD2') "R(#10)" : CRT OCONV(VAR3, 'MD4') "R(#14)" ; ** end of output line ...and it works perfectly. So, since FMT isn't (or at least hasn't been) as portable as the string formating code (FMT wasn't part of the Adds, GA, R83, AdvPick, D3 line of MV), I'd say using FMT violates the guideline of "make it portable". Just a thought... Bill >Womack, Adrian wrote: >> IMO, the only thing wrong with your example is the use of the trailing >> format strings - everyone (and I mean everyone) should be using the FMT >> function, making your example: >> >> CRT FMT(OCONV(VAR1,"MD0"),"R#6 "):FMT(OCONV(VAR2,"MD2"),"R#10 >> "):FMT(OCONV(VAR3,"MD4"),"R#14") >> >> The old method is a disaster waiting to happen. >> >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming >> Sent: Tuesday, 20 November 2007 2:12 PM >> To: u2-users@listserver.u2ug.org >> Subject: Re: [U2] OCONV Extraction Question - Good Practice >> >> Here begins the voting for differences. >> >> I actually do not care for the inclusion of the extra Var1.F variables >> as, mentioned earlier, is that variable used elsewhere? Plus, it implies >> that it maybe part of a calculation instead of an upcoming, disposable >> CRT statement. >> >> Will I rot as I use this CRT statement? >> >> CRT OCONV(VAR1,"MD0")"R#6':" ":OCONV(VAR2,"MD2")"R#10":" >> ":OCONV(VAR3,"MD4")"R#14". --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] OCONV Extraction Question - Good Practice
I'm not as concerned about the old style format strings as I am about the readability of the code and ease of future modification concerning the printed (CRT'd in this case) string. I'd do this: OUT.LINE = FMT(OCONV(VAR1,"MD0"),"R#6 ") OUT.LINE := FMT(OCONV(VAR2,"MD2"),"R#10") OUT.LINE := FMT(OCONV(VAR3,"MD4"),"R#14") CRT OUT.LINE Womack, Adrian wrote: > IMO, the only thing wrong with your example is the use of the trailing > format strings - everyone (and I mean everyone) should be using the FMT > function, making your example: > > CRT FMT(OCONV(VAR1,"MD0"),"R#6 "):FMT(OCONV(VAR2,"MD2"),"R#10 > "):FMT(OCONV(VAR3,"MD4"),"R#14") > > The old method is a disaster waiting to happen. > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming > Sent: Tuesday, 20 November 2007 2:12 PM > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] OCONV Extraction Question - Good Practice > > Here begins the voting for differences. > > I actually do not care for the inclusion of the extra Var1.F variables > as, mentioned earlier, is that variable used elsewhere? Plus, it implies > that it maybe part of a calculation instead of an upcoming, disposable > CRT statement. > > Will I rot as I use this CRT statement? > > CRT OCONV(VAR1,"MD0")"R#6':" ":OCONV(VAR2,"MD2")"R#10":" > ":OCONV(VAR3,"MD4")"R#14". > > > > DISCLAIMER: > Disclaimer. This e-mail is private and confidential. If you are not the > intended recipient, please advise us by return e-mail immediately, and delete > the e-mail and any attachments without using or disclosing the contents in > any way. The views expressed in this e-mail are those of the author, and do > not represent those of this company unless this is clearly indicated. You > should scan this e-mail and any attachments for viruses. This company accepts > no liability for any direct or indirect damage or loss resulting from the use > of any attachments to this e-mail. > --- > 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] OCONV Extraction Question - Good Practice
I don't like it. I've been in the language for over 25 years and have passed the certification a couple of times and when I looked at this I was scratching my head for a while. Obviously you know what you are doing but what is going to happen with the next programmer when you retire. -Original Message- From: MAJ Programming [mailto:[EMAIL PROTECTED] Sent: Monday, November 19, 2007 11:12 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] OCONV Extraction Question - Good Practice Oddly enough, to make things more interesting, I would have coded it this way: CRT VAR1"R0#6":" ":VAR2/100"R2#10":" ":VAR3/1"R4#14" Less typing. For output, the only time I use OCONV is a "MTx" time conversion or if the value isn't justified and I want the all the decimals. I use DATE()"D2/" beaucoups of times. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] OCONV Extraction Question - Good Practice
IMO, the only thing wrong with your example is the use of the trailing format strings - everyone (and I mean everyone) should be using the FMT function, making your example: CRT FMT(OCONV(VAR1,"MD0"),"R#6 "):FMT(OCONV(VAR2,"MD2"),"R#10 "):FMT(OCONV(VAR3,"MD4"),"R#14") The old method is a disaster waiting to happen. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming Sent: Tuesday, 20 November 2007 2:12 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] OCONV Extraction Question - Good Practice Here begins the voting for differences. I actually do not care for the inclusion of the extra Var1.F variables as, mentioned earlier, is that variable used elsewhere? Plus, it implies that it maybe part of a calculation instead of an upcoming, disposable CRT statement. Will I rot as I use this CRT statement? CRT OCONV(VAR1,"MD0")"R#6':" ":OCONV(VAR2,"MD2")"R#10":" ":OCONV(VAR3,"MD4")"R#14". DISCLAIMER: Disclaimer. This e-mail is private and confidential. If you are not the intended recipient, please advise us by return e-mail immediately, and delete the e-mail and any attachments without using or disclosing the contents in any way. The views expressed in this e-mail are those of the author, and do not represent those of this company unless this is clearly indicated. You should scan this e-mail and any attachments for viruses. This company accepts no liability for any direct or indirect damage or loss resulting from the use of any attachments to this e-mail. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] OCONV Extraction Question - Good Practice
Here begins the voting for differences. I actually do not care for the inclusion of the extra Var1.F variables as, mentioned earlier, is that variable used elsewhere? Plus, it implies that it maybe part of a calculation instead of an upcoming, disposable CRT statement. Will I rot as I use this CRT statement? CRT OCONV(VAR1,"MD0")"R#6':" ":OCONV(VAR2,"MD2")"R#10":" ":OCONV(VAR3,"MD4")"R#14". If so, I wonder how much company I'll have. My 1 cent. Oddly enough, to make things more interesting, I would have coded it this way: CRT VAR1"R0#6":" ":VAR2/100"R2#10":" ":VAR3/1"R4#14" Less typing. For output, the only time I use OCONV is a "MTx" time conversion or if the value isn't justified and I want the all the decimals. I use DATE()"D2/" beaucoups of times. ----- Original Message - From: "Brutzman, Bill" <[EMAIL PROTECTED]> To: Sent: Monday, November 19, 2007 2:41 PM Subject: RE: [U2] OCONV Extraction Question - Good Practice > The problem of printing non-atomic data gets worse when doing reports with > tables, that is, long lines with several variables. Consider the following > remedy. The alternative is a nightmare. > > --Bill > > >>> Speaking of mis-used commands and side-stepping some of the given code > >>> craziness... > >>> > >>> It is better practice to atomize the code into discrete elements such > >>> as... > > Var1.F = oconv(Var1, 'MD0') > Var2.F = oconv(Var2, 'MD2') > Var3.F = oconv(Var3, 'MD4') > > Crt.Str = Var1.F 'R#6 > Crt.Str := Var2.R 'R#12' > Crt.Str := Var3.F 'R#14' > crt Crt.Str > > > >>> rather than to try to kill two birds with one stone by including an > >>> oconv statement inside a crt statement such as... > >>> > >>> crt oconv(Var1, 'MD0') > >>> > >>> --Bill> > --- > 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] OCONV Extraction Question - Good Practice
The problem of printing non-atomic data gets worse when doing reports with tables, that is, long lines with several variables. Consider the following remedy. The alternative is a nightmare. --Bill >>> Speaking of mis-used commands and side-stepping some of the given code >>> craziness... >>> >>> It is better practice to atomize the code into discrete elements such >>> as... Var1.F = oconv(Var1, 'MD0') Var2.F = oconv(Var2, 'MD2') Var3.F = oconv(Var3, 'MD4') Crt.Str = Var1.F 'R#6 Crt.Str := Var2.R 'R#12' Crt.Str := Var3.F 'R#14' crt Crt.Str >>> rather than to try to kill two birds with one stone by including an >>> oconv statement inside a crt statement such as... >>> >>> crt oconv(Var1, 'MD0') >>> >>> --Bill> --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
