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: [U2] OCONV Extraction Question
D wrote: > VAR1 = 'SAM':@VM:'TRUDY' > CRT OCONV(VAR1,'WHATEVER') > > What replaces WHATEVER, so that I can see the value "SAM"? I cannot find in > the documentation or remember for that matter how to extract a single value > using the OCONV function. > > Thanks in advance, > Doug I tried using a "G" conversion, but it didn't like the system mark in the middle: CRT OCONV(VAR1,"G0":@VM:"1") I don't know why you'd want to do what you've described. Specifically, people use @AM, @VM, and @SM so that the standard EXTRACT functions can be used. My code would look like this: CRT VAR1<1,1> Which is about as clear as you can get. Dave Barrett, Lawyers' Professional Indemnity Company --- 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 - Best Practises
I am living that mess of the 'future maintainer' right now. I've inherited 2 systems due to the prior programmer leaving town and while that programmer was very smart and had a good memory for the 10+ years of code he wrote, he barely commented anything, has ambiguous program and file names and, due to working 80% with The Programmer's Helper, everything is inconsistently abbreviated. So I figure that 10-15% of what I'm typing is not code but comments. I put comments in programs declaring why I am reviewing it in the first place and what it's attached to. I have a DICT README record in every data file for its nominal purpose and other commentary. I wrote a FIND.ALL program to review every BP file, Proc and MD in these multi-account systems to see if program FIX.RECORD-3 is used anywhere or a one-shot 'programmer's program. I have programs that sniff out OPEN attempted files that STOP upon failure to consider archiving the program out of the mainline BP files. All of this exposure of bad techiques will help many people develop their own Best Practices. MJ - Original Message - From: "Kevin King" <[EMAIL PROTECTED]> To: Sent: Monday, November 19, 2007 1:17 PM Subject: Re: [U2] OCONV Extraction Question - Best Practises > In response to Susan's mention of the criteria for evaluating code, I > submit that I personally verify code against three criteria: > > 1) Is it accurate? Does it fulfill its designed mission? Often times > code misses this mark simply because of the shifting sands of > requirements, and what might have been accurate six months ago may no > longer be so. > > 2) Does it perform as well as it could? This is where the multiple > READV/WRITEV thing falls down, as it may not be the most efficient way > of achieving a given objective. > > 3) Is it maintainable? This goes far beyond "readable" to include > elements to strengthen comprehension of the context and intended > objective and how the source code interprets the implementation of > that objective. This includes standardized code fragments and > structures, predictable and consistent variable naming conventions, > intentional use and avoidance of certain language elements (such as GE > verses >= for comparison) and commenting styles and standards. > > Too often, as Susan has pointed out, programmers write code to make > today's problem go away because there are a dozen or more projects > lined up behind it, instead of writing the code thinking of the guy > who will be reading the code several months from now. I submit that > we should always keep the future maintainer in mind, assuming that > they know nothing of the context, little of the problem, and less time > than needed to achieve their objective. If we don't set the stage for > that person's success, we shouldn't be surprised when they don't > describe our work in the most complimentary of terms. > --- > 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
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 - Best Practises
I'm all for exposing my personal techniques and watching the flames come. Granted, there will be some holy wars but in the end, many ambiguous conditions may be solved one way or another. I have exposed my personal techniques for many years on these forums and will defend them as I understand the offenders. I am also smart enough to change a technique if I see a better one. It doesn't have to be voted unanimously to be my favorite. We all can tell what techniques will fit comfortably with our existing skills. I, for one, do not care for the EQU CUST.NAME to CUSTOMER(1) style of coding. I do not like using attr 99 for calculated dictionary items (sorry, that's another forum). I have my own preferred way of opening files, file handle names, and even constructively mixing numeric with alphabetic labels. While there will be no winners, everyone will be a winner as we all will become exposed to other techniques that many of us may not have had the luxury of reviewing many different systems. I can't wait. Mark Johnson PS. Hopefully this doesn't become an artistic expression of grandeur. Meaning, if the chapter was the best way to multiply 2 numbers together, A=B*C must win. If someone submits A=e^(ln(B)+ln(C)) then that misses the point. - Original Message - From: "Kevin King" <[EMAIL PROTECTED]> To: Sent: Monday, November 19, 2007 12:07 PM Subject: Re: [U2] OCONV Extraction Question - Best Practises > I'd play on that field, Chuck. Not looking for a flame war, but I > know there are a lot of people with some great ideas and there's much > to be gained by keeping the lines of communication open. Then again, > topics like alpha vs. numeric labels could turn out to be massively > polarizing. > --- > 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 - Best Practises
I would be in favor of chapterizing the various coding concepts into a greatest hits collection. As I have transversed perhaps 35 different MV systems during my career, I have had the chance to view many practices, both good and bad. I add the good ones to my collection (always willing to learn) and scratch my head at some of the crazy ones. I do give the benefit of the doubt in some cases as I can 'age' the programs and personally recall the available thought processes at the time. But also having been around since almost the beginning, I can see when some commands were used when the better ones were certainly available. Thus, those fall into the 'bad' category. Example of a bad technique that has no reason for its use: WHOLE.NAME="MARK JOHNSON" II=INDEX(WHOLE.NAME," ",1) FIRST.NAME=WHOLE.NAME[1,II-1] ain't that called the FIELD command. Things like that. My 2 cents Mark Johnson - Original Message - From: "Baker Hughes" <[EMAIL PROTECTED]> To: Sent: Monday, November 19, 2007 10:17 AM Subject: RE: [U2] OCONV Extraction Question - Best Practises > It's JUST a preference, presently > > I know we all reach for a good balance between brevity and clarity. > > I have some preferences too which I think are ideal, which seem less > than ideal to others. > > ... but rather than mount my own hobby horse I have a suggestion / > question that could put these types of exchanges to rest: > > WHAT IF - the U2UG took it as a future project to compile a Best > Practices coding guideline document for our language? > > There's always helpful 'How to' stuff exchanged here. ...but style > question sometimes spiral downward. > > As someone pointed out recently, we have the blessing and curse of using > a rather free style language. > Not much Structure-Style is not imposed by the construct of the language > itself, like some others. > > Is it time to codify some best practices relating to structure, > modularity, reuse, length of internal subs, etc? > > I may not like some of the resulting definitions myself but it would > build cohesion and greater respect for the MV space. > Another thing it would do is chart a clearer path for those coming > behind us - we need new blood if the VARs in this space are going to > continue to sell/support embedded MV apps. > > I would personally find it fascinating to see some of our venerable > coders get together and see what they produced along this line. I have > some names in mind but I'll wait for the nominations to officially open. > > Happy Thanksgiving. > > -Baker > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming > Sent: Saturday, November 17, 2007 12:58 AM > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] OCONV Extraction Question > > According to who? > > I know there are some pluses and minuses but where is this decided or is > it just a preference. > > Thanks > Mark Johnson > - Original Message - > From: "Brutzman, Bill" <[EMAIL PROTECTED]> > To: > Sent: Friday, November 16, 2007 11:30 AM > Subject: RE: [U2] OCONV Extraction Question > > > > 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') > > crt Var1.F 'R#11' > > > > 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 > > > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of MAJ > > Programming > > Sent: Friday, November 16, 2007 12:48 AM > > To: u2-users@listserver.u2ug.org > > Subject: Re: [U2] OCONV Extraction Question > > > > > > This is real smart, making things harder than they should be. Just use > <>. > > > > Mark Johnson > > - Original Message - > > From: <[EMAIL PROTECTED]> > > To: > > Sent: Wednesday, November 14, 2007 5:23 PM > > Subject: RE: [U2] OCONV Extraction Question > > > > > > > Didn't work for me either. It may not fit what you need, but SWAP > > > can > make > > > it work. > > > > > > VAR1 = 'SAM':@VM:'TRUDY' > > > SWAP @VM WITH '*' IN VAR1 > > > FMTSTR = 'G*1' > > > CRT OCONV(VAR1,FMTSTR) > > > > > > Bra
Re: [U2] OCONV Extraction Question - Best Practises
Charles: GREAT point! In the overarching scheme of things, we should never forget that while original implementation has a fixed timeline, maintenance can be forever. More importantly, the costs of each are commensurate with its lifetime. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] OCONV Extraction Question - Best Practises
Great discussion! One thing that I have learned in my 25 years in IT is that early on, I underestimated the importance of maintainability. I noticed this when I got into management. I had a programmer who seemed to be slow, but when you looked at her code, it was BEAUTIFUL. Anyone could easily modify her code because she made the intent SO obvious through structure and comments. The time saved working with her code FAR outweighed the extra time she took coding it. Charles Shaffer Senior Analyst NTN-Bower Corporation --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] OCONV Extraction Question - Best Practises
Susan,
All of which makes the determination of "best practices" rather
difficult, since it depends on the criteria you choose for the
evaluation - efficiency? Ease of maintenance? Conformation to 'site
standards'? Ability to call a logical module from multiple locations in
the wider application? Auditability of the results? Various standards
of presentation of data for the user interface? Once you get beyond the
very simple aspects of programming, everything has to be judged in the
context of the application as a whole, rather than on the brilliance (or
lack thereof) of small code fragments.
Susan Lynch
If there were a set of best practices, no one would expect old code to
conform to it, only new or re-factored code.
Obviously, if you are working with 20 year old code, as many of us are,
you have a huge limitation out of the box (unless you have unlimited
freedom to re-write your app [and multiply QA time exponentially]). The
purpose of any 'best practices' document{s) would be to set forth ideal
methodologies. It is up to the art and skill of the individual
programmer to incorporate those methodologies, insofar as s/he can, into
their every project.
However, well formed, well structured, modular code will satisfy all the
evaluation points you mentioned. The one sticky point could be 'site
standards' - but hopefully those sites that have arcane 'standards'
would consider the weight and authority of a 'industry recognized' [De
Facto] standard 'best practices' document, and change their archaic
ways.
just my .002
-Baker
---
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/
RE: [U2] OCONV Extraction Question - Best Practises
Susan: See. This brings up the difference between coding styles and guidelines. The guidline is: If you use it once use it once. If you use it twice either create a variable or a local subroutine. If it's used in more than one program then either create a common variable or a separate subroutine. You get the idea. Now we expose ourselves to style. Style 1: OfficeRec(5) = OfficeRec(6) * OfficeRec(7) Style 2: EQUATE OfficeSize to OfficeRec(4) OfficeWidth = OfficeRec(6) OfficeDepth = OfficeRec(7) OfficeSize = OfficeWidth * OfficeDepth I think this demonstrates the style differences between brevity and clarity. Style 1 accomplishes exactly what's needed while style 2 reflects the need for clarity of what's actually being done. Often I simply add a comment to Style 1 like: Style 1 (amended): OfficeRec(5) = OfficeRec(6) * OfficeRec(7) ; ** the size of the office in square footage However, as you say, if I'm using any of the variables elsewhere in the code, or was referencing a dynamic instead of a dimensioned array for OfficeRec, I'd much prefer Style 2. So it seems to me there really is a difference between style and guidelines. :-) Bill >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Susan Lynch >Sent: Monday, November 19, 2007 9:25 AM >To: u2-users@listserver.u2ug.org >Subject: Re: [U2] OCONV Extraction Question - Best Practises > >Actually, that brings up an important point - my preference would be that >if you are going to do it once and never re-use that value, then it probably >makes sense to do it in one line, and not add the additional variable, but >if you are going to need it again, as the OCONV'd value, it makes sense to >set a new variable to the OCONV'd value and use the variable, rather than >re-doing the oconv. [snipped] >Susan Lynch > >- Original Message - >From: "Anthony Youngman" <[EMAIL PROTECTED]> >To: >Sent: Monday, November 19, 2007 11:19 AM >Subject: RE: [U2] OCONV Extraction Question - Best Practises > > >> Just DON'T start a few flame wars over this :-) >> >> I'd actually vehemently disagree with the original suggestion, for several >> reasons. The two biggest are: >> >> It introduces an extra variable. Any poor maintenance guy coming along has >> to worry about whether it's used elsewhere. This sort of behaviour is >> actually frowned on in ANY programming language, I believe. >> >> And my personal reason for disliking it, over and above the previous - it >> takes two lines where one would do. Okay, compressing code for the sake of >> it can hinder comprehension, but I like tight, compact code with >> white-space separating small sections, not individual sections full of >> white space... >> >> Cheers, >> Wol >> >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Baker Hughes >> Sent: 19 November 2007 15:18 >> To: u2-users@listserver.u2ug.org >> Subject: RE: [U2] OCONV Extraction Question - Best Practises >> >> It's JUST a preference, presently [snipped] >>> 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') >>> crt Var1.F 'R#11' >>> >>> 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/
Re: [U2] OCONV Extraction Question - Best Practises
In response to Susan's mention of the criteria for evaluating code, I submit that I personally verify code against three criteria: 1) Is it accurate? Does it fulfill its designed mission? Often times code misses this mark simply because of the shifting sands of requirements, and what might have been accurate six months ago may no longer be so. 2) Does it perform as well as it could? This is where the multiple READV/WRITEV thing falls down, as it may not be the most efficient way of achieving a given objective. 3) Is it maintainable? This goes far beyond "readable" to include elements to strengthen comprehension of the context and intended objective and how the source code interprets the implementation of that objective. This includes standardized code fragments and structures, predictable and consistent variable naming conventions, intentional use and avoidance of certain language elements (such as GE verses >= for comparison) and commenting styles and standards. Too often, as Susan has pointed out, programmers write code to make today's problem go away because there are a dozen or more projects lined up behind it, instead of writing the code thinking of the guy who will be reading the code several months from now. I submit that we should always keep the future maintainer in mind, assuming that they know nothing of the context, little of the problem, and less time than needed to achieve their objective. If we don't set the stage for that person's success, we shouldn't be surprised when they don't describe our work in the most complimentary of terms. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] OCONV Extraction Question - Best Practises
My personal preference is to atomize. This goes back to my C days. I found that while it was possible to cram a lot of code into one line, there were portability problems. The same code could compile differently on different platforms depending on how the C compiler handled the complex lines. I don't know if there are similar issues with UniBasic, or not. Also, I personally find the atomized code easier to read and more explicit. Charles Shaffer Senior Analyst NTN-Bower Corporation >Just DON'T start a few flame wars over this :-) >I'd actually vehemently disagree with the original suggestion, for several reasons. The two biggest are: >It introduces an extra variable. Any poor maintenance guy coming along has to worry about whether it's used elsewhere. This sort of behaviour is >actually frowned on in ANY programming language, I believe. >And my personal reason for disliking it, over and above the previous - it takes two lines where one would do. Okay, compressing code for the sake of >it can hinder comprehension, but I like tight, compact code with white-space separating small sections, not individual sections full of white >space... >Cheers, >Wol > 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') > crt Var1.F 'R#11' > > 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/
Re: [U2] OCONV Extraction Question - Best Practises
I'd play on that field, Chuck. Not looking for a flame war, but I know there are a lot of people with some great ideas and there's much to be gained by keeping the lines of communication open. Then again, topics like alpha vs. numeric labels could turn out to be massively polarizing. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] OCONV Extraction Question - Best Practises
Actually, that brings up an important point - my preference would be that if you are going to do it once and never re-use that value, then it probably makes sense to do it in one line, and not add the additional variable, but if you are going to need it again, as the OCONV'd value, it makes sense to set a new variable to the OCONV'd value and use the variable, rather than re-doing the oconv. But that requires that a maintenance programmer take the time to know the program rather than look at the surrounding 20 lines or so (and their performance is probably evaluated on how fast they get the changes made rather than on their effect on the quality of the code), which is why most of us have so often seen (particularly in programs generated by a code-generator or in programs maintained by a variety of people over many years) multiple READV's and WRITEV's rather than a single read of the record, or multiple OCONV's of the exact same field with the exact same masking. But making the decision based on the need is my personal preference - others may prefer a standardized approach for ease of training new programmers or may argue that "disk is cheap, memory is cheap" and prefer not to focus on efficiency as one of the criteria for evaluating code. All of which makes the determination of "best practices" rather difficult, since it depends on the criteria you choose for the evaluation - efficiency? Ease of maintenance? Conformation to 'site standards'? Ability to call a logical module from multiple locations in the wider application? Auditability of the results? Various standards of presentation of data for the user interface? Once you get beyond the very simple aspects of programming, everything has to be judged in the context of the application as a whole, rather than on the brilliance (or lack thereof) of small code fragments. Susan Lynch - Original Message - From: "Anthony Youngman" <[EMAIL PROTECTED]> To: Sent: Monday, November 19, 2007 11:19 AM Subject: RE: [U2] OCONV Extraction Question - Best Practises Just DON'T start a few flame wars over this :-) I'd actually vehemently disagree with the original suggestion, for several reasons. The two biggest are: It introduces an extra variable. Any poor maintenance guy coming along has to worry about whether it's used elsewhere. This sort of behaviour is actually frowned on in ANY programming language, I believe. And my personal reason for disliking it, over and above the previous - it takes two lines where one would do. Okay, compressing code for the sake of it can hinder comprehension, but I like tight, compact code with white-space separating small sections, not individual sections full of white space... Cheers, Wol -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Baker Hughes Sent: 19 November 2007 15:18 To: u2-users@listserver.u2ug.org Subject: RE: [U2] OCONV Extraction Question - Best Practises It's JUST a preference, presently [SNIP] [END SNIP] 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') crt Var1.F 'R#11' 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/
RE: [U2] OCONV Extraction Question - Best Practises
Just DON'T start a few flame wars over this :-) I'd actually vehemently disagree with the original suggestion, for several reasons. The two biggest are: It introduces an extra variable. Any poor maintenance guy coming along has to worry about whether it's used elsewhere. This sort of behaviour is actually frowned on in ANY programming language, I believe. And my personal reason for disliking it, over and above the previous - it takes two lines where one would do. Okay, compressing code for the sake of it can hinder comprehension, but I like tight, compact code with white-space separating small sections, not individual sections full of white space... Cheers, Wol -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Baker Hughes Sent: 19 November 2007 15:18 To: u2-users@listserver.u2ug.org Subject: RE: [U2] OCONV Extraction Question - Best Practises It's JUST a preference, presently I know we all reach for a good balance between brevity and clarity. I have some preferences too which I think are ideal, which seem less than ideal to others. ... but rather than mount my own hobby horse I have a suggestion / question that could put these types of exchanges to rest: WHAT IF - the U2UG took it as a future project to compile a Best Practices coding guideline document for our language? There's always helpful 'How to' stuff exchanged here. ...but style question sometimes spiral downward. As someone pointed out recently, we have the blessing and curse of using a rather free style language. Not much Structure-Style is not imposed by the construct of the language itself, like some others. Is it time to codify some best practices relating to structure, modularity, reuse, length of internal subs, etc? I may not like some of the resulting definitions myself but it would build cohesion and greater respect for the MV space. Another thing it would do is chart a clearer path for those coming behind us - we need new blood if the VARs in this space are going to continue to sell/support embedded MV apps. I would personally find it fascinating to see some of our venerable coders get together and see what they produced along this line. I have some names in mind but I'll wait for the nominations to officially open. Happy Thanksgiving. -Baker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming Sent: Saturday, November 17, 2007 12:58 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] OCONV Extraction Question According to who? I know there are some pluses and minuses but where is this decided or is it just a preference. Thanks Mark Johnson - Original Message - From: "Brutzman, Bill" <[EMAIL PROTECTED]> To: Sent: Friday, November 16, 2007 11:30 AM Subject: RE: [U2] OCONV Extraction Question > 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') > crt Var1.F 'R#11' > > 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 > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of MAJ > Programming > Sent: Friday, November 16, 2007 12:48 AM > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] OCONV Extraction Question > > > This is real smart, making things harder than they should be. Just use <>. > > Mark Johnson > - Original Message - > From: <[EMAIL PROTECTED]> > To: > Sent: Wednesday, November 14, 2007 5:23 PM > Subject: RE: [U2] OCONV Extraction Question > > > > Didn't work for me either. It may not fit what you need, but SWAP > > can make > > it work. > > > > VAR1 = 'SAM':@VM:'TRUDY' > > SWAP @VM WITH '*' IN VAR1 > > FMTSTR = 'G*1' > > CRT OCONV(VAR1,FMTSTR) > > > > Brad > > > > > > U.S. BANCORP made the following annotations > > > > - Electronic Privacy Notice. This e-mail, and any attachments, > > contains > information that is, or may be, covered by electronic communications privacy > laws, and is also confidential and proprietary in nature. If you are > not the > intended recipient, please be advised that you are legally prohibited > from retaining, using, copying, distributing, or otherwise disclosing > this information in any manner. Instead, please reply to the sender > that you have > received this communication in error, and then immediately delete it
Re: [U2] OCONV Extraction Question - Best Practises
Baker, I agree, but the path is hard and the way is murky. A few months back, I posted a free skeleton maker, which implemented some reasonable commenting. When I opened it up to the list for comments, the response was greatly varied. Some people even replied privately for fear of starting a flame war on the lists. If we are going to do as you suggested, I only see one way to make that work: Let's get a few people to each write up their own style guideline and subject them all to the list's opinions, with each originator having a final say on their guideline. We can post them all to U2UG.org and let people select the one they like. it won't have the value of setting a single style, but it has the value of being possible. Anyone frustrated with all choices can petition the author who is closest or they can roll their own and subject it to feedback. Anyone willing to step up? I'd be willing to play under these terms. - Chuck Baker Hughes wrote: WHAT IF - the U2UG took it as a future project to compile a Best Practices coding guideline document for our language? --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] OCONV Extraction Question - Best Practises
It's JUST a preference, presently I know we all reach for a good balance between brevity and clarity. I have some preferences too which I think are ideal, which seem less than ideal to others. ... but rather than mount my own hobby horse I have a suggestion / question that could put these types of exchanges to rest: WHAT IF - the U2UG took it as a future project to compile a Best Practices coding guideline document for our language? There's always helpful 'How to' stuff exchanged here. ...but style question sometimes spiral downward. As someone pointed out recently, we have the blessing and curse of using a rather free style language. Not much Structure-Style is not imposed by the construct of the language itself, like some others. Is it time to codify some best practices relating to structure, modularity, reuse, length of internal subs, etc? I may not like some of the resulting definitions myself but it would build cohesion and greater respect for the MV space. Another thing it would do is chart a clearer path for those coming behind us - we need new blood if the VARs in this space are going to continue to sell/support embedded MV apps. I would personally find it fascinating to see some of our venerable coders get together and see what they produced along this line. I have some names in mind but I'll wait for the nominations to officially open. Happy Thanksgiving. -Baker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MAJ Programming Sent: Saturday, November 17, 2007 12:58 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] OCONV Extraction Question According to who? I know there are some pluses and minuses but where is this decided or is it just a preference. Thanks Mark Johnson - Original Message - From: "Brutzman, Bill" <[EMAIL PROTECTED]> To: Sent: Friday, November 16, 2007 11:30 AM Subject: RE: [U2] OCONV Extraction Question > 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') > crt Var1.F 'R#11' > > 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 > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of MAJ > Programming > Sent: Friday, November 16, 2007 12:48 AM > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] OCONV Extraction Question > > > This is real smart, making things harder than they should be. Just use <>. > > Mark Johnson > - Original Message - > From: <[EMAIL PROTECTED]> > To: > Sent: Wednesday, November 14, 2007 5:23 PM > Subject: RE: [U2] OCONV Extraction Question > > > > Didn't work for me either. It may not fit what you need, but SWAP > > can make > > it work. > > > > VAR1 = 'SAM':@VM:'TRUDY' > > SWAP @VM WITH '*' IN VAR1 > > FMTSTR = 'G*1' > > CRT OCONV(VAR1,FMTSTR) > > > > Brad > > > > > > U.S. BANCORP made the following annotations > > > > - Electronic Privacy Notice. This e-mail, and any attachments, > > contains > information that is, or may be, covered by electronic communications privacy > laws, and is also confidential and proprietary in nature. If you are > not the > intended recipient, please be advised that you are legally prohibited > from retaining, using, copying, distributing, or otherwise disclosing > this information in any manner. Instead, please reply to the sender > that you have > received this communication in error, and then immediately delete it. Thank > you in advance for your cooperation. > > > > > > > > > > - > > --- > > 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] OCONV Extraction Question
According to who? I know there are some pluses and minuses but where is this decided or is it just a preference. Thanks Mark Johnson - Original Message - From: "Brutzman, Bill" <[EMAIL PROTECTED]> To: Sent: Friday, November 16, 2007 11:30 AM Subject: RE: [U2] OCONV Extraction Question > 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') > crt Var1.F 'R#11' > > 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 > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of MAJ Programming > Sent: Friday, November 16, 2007 12:48 AM > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] OCONV Extraction Question > > > This is real smart, making things harder than they should be. Just use <>. > > Mark Johnson > - Original Message - > From: <[EMAIL PROTECTED]> > To: > Sent: Wednesday, November 14, 2007 5:23 PM > Subject: RE: [U2] OCONV Extraction Question > > > > Didn't work for me either. It may not fit what you need, but SWAP can make > > it work. > > > > VAR1 = 'SAM':@VM:'TRUDY' > > SWAP @VM WITH '*' IN VAR1 > > FMTSTR = 'G*1' > > CRT OCONV(VAR1,FMTSTR) > > > > Brad > > > > > > U.S. BANCORP made the following annotations > > - > > Electronic Privacy Notice. This e-mail, and any attachments, contains > information that is, or may be, covered by electronic communications privacy > laws, and is also confidential and proprietary in nature. If you are not the > intended recipient, please be advised that you are legally prohibited from > retaining, using, copying, distributing, or otherwise disclosing this > information in any manner. Instead, please reply to the sender that you have > received this communication in error, and then immediately delete it. Thank > you in advance for your cooperation. > > > > > > > > - > > --- > > 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] OCONV Extraction Question
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') crt Var1.F 'R#11' 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 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of MAJ Programming Sent: Friday, November 16, 2007 12:48 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] OCONV Extraction Question This is real smart, making things harder than they should be. Just use <>. Mark Johnson - Original Message - From: <[EMAIL PROTECTED]> To: Sent: Wednesday, November 14, 2007 5:23 PM Subject: RE: [U2] OCONV Extraction Question > Didn't work for me either. It may not fit what you need, but SWAP can make > it work. > > VAR1 = 'SAM':@VM:'TRUDY' > SWAP @VM WITH '*' IN VAR1 > FMTSTR = 'G*1' > CRT OCONV(VAR1,FMTSTR) > > Brad > > > U.S. BANCORP made the following annotations > - > Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation. > > > > - > --- > 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
This is real smart, making things harder than they should be. Just use <>. Mark Johnson - Original Message - From: <[EMAIL PROTECTED]> To: Sent: Wednesday, November 14, 2007 5:23 PM Subject: RE: [U2] OCONV Extraction Question > Didn't work for me either. It may not fit what you need, but SWAP can make > it work. > > VAR1 = 'SAM':@VM:'TRUDY' > SWAP @VM WITH '*' IN VAR1 > FMTSTR = 'G*1' > CRT OCONV(VAR1,FMTSTR) > > Brad > > > U.S. BANCORP made the following annotations > - > Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation. > > > > - > --- > 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
This is a case of mis-used commands. MV allows for many ways to skin a cat. In this case, the <> is the most effecient. You can use the function EXTRACT, FIELD and OCONV but the <> is the best. Unless you/ve inherited code from over 25 years ago, the <> wins. Back then, the <> didn't exist and you had to use EXTRACT which caused people to consider FIELD. The only advantage to using OCONV with the G conversion is if you want more than a single element, aka G0*2 or [EMAIL PROTECTED] (sic). It's almost a no brainer to use <>. The others are all too cumbersome and don't read that easily. My 2 cents. Mark Johnson - Original Message - From: <[EMAIL PROTECTED]> To: Sent: Wednesday, November 14, 2007 3:22 PM Subject: RE: [U2] OCONV Extraction Question > Doug, > > Any reason you need to use OCONV() instead of FIELD()? > > Brian > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of D > Sent: Wednesday, November 14, 2007 1:05 PM > To: u2-users@listserver.u2ug.org > Subject: [U2] OCONV Extraction Question > > VAR1 = 'SAM':@VM:'TRUDY' > CRT OCONV(VAR1,'WHATEVER') > > What replaces WHATEVER, so that I can see the value "SAM"? I cannot find in > the documentation or remember for that matter how to extract a single value > using the OCONV function. > > Thanks in advance, > Doug > --- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material not intended for Public use. > Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is > strictly prohibited. If you received this communication in error, please notify the sender and delete the material from any and all computers or devices. > --- > 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
And yet in UD you can 001: V 002: FIELD(F59,@VM,1) Interesting Bruce Bruce M Neylon Health Care Management Group Phone: (301) 608-8633 <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 11/15/2007 12:01 PM Please respond to u2-users@listserver.u2ug.org To cc Subject RE: [U2] OCONV Extraction Question Of course, UniData just has to be different. 1. 'MCP' doesn't convert system delimiters 2. 'MCP' converts to a '~' not a '.' The @VM does work to stack commands - so 'G':@VM:'1' won't work in UD either (although the rest of the system delimiters work). Also, because UD applies the OCONV across all values in an array you can't even cheat and use T1,3 (even assuming you know the length of the text). Colin Alfke Calgary Canada --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] OCONV Extraction Question
Of course, UniData just has to be different. 1. 'MCP' doesn't convert system delimiters 2. 'MCP' converts to a '~' not a '.' The @VM does work to stack commands - so 'G':@VM:'1' won't work in UD either (although the rest of the system delimiters work). Also, because UD applies the OCONV across all values in an array you can't even cheat and use T1,3 (even assuming you know the length of the text). Colin Alfke Calgary Canada -Original Message- From: Stevenson, Charles 'MCP':@VM:'G.1' is the exact answer your exact question of what can replace 'WHATEVER' in your code. The complete code becomes VAR1 = 'SAM':@VM:'TRUDY' CRT OCONV(VAR1,'MCP':@VM:'G.1') This answer will work as long as there aren't any real periods in VAR1. In the 2nd argument, you can stack successively executed conversion codes separated by value marks. Each acts on the output of the previous conversion. So above, the first conversion, "MCP", changes thevalue mark to a period. The second, "G.1" extracts the 1st group deliminated by periods. This also explains why OCONV(VAR1, 'G':@VM:'1') doesn't work. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] OCONV Extraction Question
My general comment is to use the appropriate extraction function for the task. If wanting to extract an attribute, value, or subvalue, then use the "<>" reference or EXTRACT() function. If working with strings then use the OCONV() or FIELD() functions. There are additional functions for specialized tasks but this rule should suffice for your needs. HTH, Bill >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of >[EMAIL PROTECTED] >Sent: Wednesday, November 14, 2007 2:24 PM >To: u2-users@listserver.u2ug.org >Subject: RE: [U2] OCONV Extraction Question > >Didn't work for me either. It may not fit what you need, but SWAP can make >it work. > >VAR1 = 'SAM':@VM:'TRUDY' >SWAP @VM WITH '*' IN VAR1 >FMTSTR = 'G*1' >CRT OCONV(VAR1,FMTSTR) > >Brad --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] OCONV Extraction Question
'MCP':@VM:'G.1' is the exact answer your exact question of what can replace 'WHATEVER' in your code. The complete code becomes VAR1 = 'SAM':@VM:'TRUDY' CRT OCONV(VAR1,'MCP':@VM:'G.1') This answer will work as long as there aren't any real periods in VAR1. In the 2nd argument, you can stack successively executed conversion codes separated by value marks. Each acts on the output of the previous conversion. So above, the first conversion, "MCP", changes thevalue mark to a period. The second, "G.1" extracts the 1st group deliminated by periods. This also explains why OCONV(VAR1, 'G':@VM:'1') doesn't work. OCONV does not care about system delimiters in the 1st argument. It acts on the entire string. OCONVS (with an "S") does care. ICONV & ICONVS make the same distinction. People have mentioned the obvious dump of OCONV for just VAR1<1,1>, but I asssume you've just condensed some complicated real-world problem down to a simplistic case. Chuck -Original Message- From: D VAR1 = 'SAM':@VM:'TRUDY' CRT OCONV(VAR1,'WHATEVER') What replaces WHATEVER, so that I can see the value "SAM"? I cannot find in the documentation or remember for that matter how to extract a single value using the OCONV function. Thanks in advance, Doug --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] OCONV Extraction Question
It's either a UniData error or Documentation error. When I try this test program I get Invalid OCONV. The documentation states, "Specifies any single nonnumeric character to be the delimiter. UniData system delimiters are valid. Hyphen or minus sign is not valid." DT = "123":@VM:"456":@VM:"789" IN.OCONV = "G":@VM:"1" NEW.DT = OCONV(DT, IN.OCONV) PRINT DT:" - ": BEGIN CASE CASE STATUS()=0 ; PRINT NEW.DT CASE STATUS()=1 ; PRINT "Data Invalid" CASE STATUS()=2 ; PRINT "Invalid OCONV ":IN.OCONV CASE STATUS()=3 ; PRINT "Possible Invalid Data ":NEW.DT CASE 1 ; PRINT "Status() Code: ":STATUS() END CASE Thanks, David A. Green www.dagconsulting.com (480) 813-1725 -Original Message- This code does not work on Unidata or Universe -Original Message- OCONV(VAR1, 'G':@VM:'1') D wrote: --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] OCONV Extraction Question
Didn't work for me either. It may not fit what you need, but SWAP can make it work. VAR1 = 'SAM':@VM:'TRUDY' SWAP @VM WITH '*' IN VAR1 FMTSTR = 'G*1' CRT OCONV(VAR1,FMTSTR) Brad U.S. BANCORP made the following annotations - Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation. - --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] OCONV Extraction Question
OCONV(VAR1, 'G':@VM:'1') D wrote: >VAR1 = 'SAM':@VM:'TRUDY' >CRT OCONV(VAR1,'WHATEVER') > >What replaces WHATEVER, so that I can see the value "SAM"? I cannot find in >the documentation or remember for that matter how to extract a single value >using the OCONV function. > >Thanks in advance, >Doug >--- >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
This code does not work on Unidata or Universe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter S. Goldberger Sent: Wednesday, November 14, 2007 12:38 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] OCONV Extraction Question OCONV(VAR1, 'G':@VM:'1') D wrote: >VAR1 = 'SAM':@VM:'TRUDY' >CRT OCONV(VAR1,'WHATEVER') > >What replaces WHATEVER, so that I can see the value "SAM"? I cannot find in >the documentation or remember for that matter how to extract a single value >using the OCONV function. > >Thanks in advance, >Doug >--- >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
Unless I'm missing something would you not.. CRT VAR1<1,1> ?? Perry Taylor ZirMed -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of D Sent: Wednesday, November 14, 2007 2:05 PM To: u2-users@listserver.u2ug.org Subject: [U2] OCONV Extraction Question VAR1 = 'SAM':@VM:'TRUDY' CRT OCONV(VAR1,'WHATEVER') What replaces WHATEVER, so that I can see the value "SAM"? I cannot find in the documentation or remember for that matter how to extract a single value using the OCONV function. Thanks in advance, Doug --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. ZirMed, Inc. has strict policies regarding the content of e-mail communications, specifically Protected Health Information, any communications containing such material will be returned to the originating party with such advisement noted. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] OCONV Extraction Question
I don't know about OCONV, but FIELD works well. VAR1 = 'SAM':@VM:'TRUDY' CRT VAR1 CRT FIELD(VAR1,@VM,1) Yields: SAM}TRUDY SAM HTH U.S. BANCORP made the following annotations - Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation. - --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] OCONV Extraction Question
Doug, Any reason you need to use OCONV() instead of FIELD()? Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of D Sent: Wednesday, November 14, 2007 1:05 PM To: u2-users@listserver.u2ug.org Subject: [U2] OCONV Extraction Question VAR1 = 'SAM':@VM:'TRUDY' CRT OCONV(VAR1,'WHATEVER') What replaces WHATEVER, so that I can see the value "SAM"? I cannot find in the documentation or remember for that matter how to extract a single value using the OCONV function. Thanks in advance, Doug --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material not intended for Public use. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is strictly prohibited. If you received this communication in error, please notify the sender and delete the material from any and all computers or devices. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] OCONV Extraction Question
I read a number of questions where I cant determine if I have more experience or less experience than the questioner. This is one of those. I'm not aware of an oconv that extracts a value, so I have to go with CRT VAR1<1,1> rather than using the OCONV, knowing that there is probably some OCONV that will do what is needed. j On 11/14/07, D <[EMAIL PROTECTED]> wrote: > VAR1 = 'SAM':@VM:'TRUDY' > CRT OCONV(VAR1,'WHATEVER') > > What replaces WHATEVER, so that I can see the value "SAM"? I cannot find in > the documentation or remember for that matter how to extract a single value > using the OCONV function. > > Thanks in advance, > Doug > --- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ > -- john --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] OCONV Extraction Question
Hi Doug, Since your variable is delimited by value marks, just use CRT VAR1<1,1> No OCONV is required. If you're using characters other than @AM, @VM, or @SM, then OCONV with the "G" option (group extraction) is your friend. For instance, if VAR1 = "SAM*TRUDY", then CRT OCONV(VAR1,'G0*1') will print SAM CRT OCONV(VAR1,'G1*1') will print TRUDY Hope this helps, Tom Derwin >>> [EMAIL PROTECTED] 11/14/07 2:05 PM >>> VAR1 = 'SAM':@VM:'TRUDY' CRT OCONV(VAR1,'WHATEVER') What replaces WHATEVER, so that I can see the value "SAM"? I cannot find in the documentation or remember for that matter how to extract a single value using the OCONV function. Thanks in advance, Doug - This e-mail and any attachments may contain CONFIDENTIAL information, including PROTECTED HEALTH INFORMATION. If you are not the intended recipient, any use or disclosure of this information is STRICTLY PROHIBITED; you are requested to delete this e-mail and any attachments, notify the sender immediately, and notify the LabCorp Privacy Officer at [EMAIL PROTECTED] or call (877) 23-HIPAA / (877) 234-4722. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] OCONV Extraction Question
I think you are looking for FIELD function not OCONV. CRT FIELD(VAR1,@VM,1) D wrote: > VAR1 = 'SAM':@VM:'TRUDY' > CRT OCONV(VAR1,'WHATEVER') > > What replaces WHATEVER, so that I can see the value "SAM"? I cannot find in > the documentation or remember for that matter how to extract a single value > using the OCONV function. > > Thanks in advance, > Doug > --- > 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
> VAR1 = 'SAM':@VM:'TRUDY' > CRT OCONV(VAR1,'WHATEVER') > > What replaces WHATEVER, so that I can see the value "SAM"? I cannot find in > the documentation or remember for that matter how to extract a single value > using the OCONV function. CRT OCONV(VAR1<1,1>,'WHATEVER') -- Jeff Butera, Ph.D. Administrative Systems Hampshire College [EMAIL PROTECTED] 413-559-5556 "That's why you have two ears and one mouth - use them accordingly." Mike Golic --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] OCONV Extraction Question
Are you sure you want it from oconv? Because this is a simple VAR<1,1>. Or you could use FIELD or EXTRACT. Then again maybe you're thinking of using a correlative like OCONV(@ID,'Tfilename;X1;20;20') to get it from a file. Jerry -Original Message- From: D [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 14, 2007 1:05 PM To: u2-users@listserver.u2ug.org Subject: [U2] OCONV Extraction Question VAR1 = 'SAM':@VM:'TRUDY' CRT OCONV(VAR1,'WHATEVER') What replaces WHATEVER, so that I can see the value "SAM"? I cannot find in the documentation or remember for that matter how to extract a single value using the OCONV function. Thanks in advance, Doug --- 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/
