RE: [U2] Text extraction.
Bill: [snip] D3 doesn't allow a SELECT to create a READNEXT list from an array so REMOVE is all D3 can use. [/snip] Are you saying that... SELECT DYN.ARRAY TO MYLIST LOOP READNEXT THING FROM MYLIST ELSE EXIT REPEAT ...does not work in D3? I think you are mistaken. My experience is that it works most excellently in D3, AP, and even R83- as a matter of fact, I think it probably works more consistently across all mv platforms than REMOVE. Are there any mv platforms that it doesn't work on? There is one caveat though: DYN.ARRAY must be @AM delimited (else you can CONVERT @VM TO @AM IN DYN.ARRAY first). /Scott Ballinger Pareto Corporation Edmonds WA USA 206 713 6006 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Text extraction.
Scott: You're correct, of course...I don't know what I was thinking. An example is even in the D3 help. The only caveat is the 1st value of each attribute is selected. Thanks for the correction. :-) Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ballinger Sent: Tuesday, August 02, 2005 10:02 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Text extraction. Bill: [snip] D3 doesn't allow a SELECT to create a READNEXT list from an array so REMOVE is all D3 can use. [/snip] Are you saying that... SELECT DYN.ARRAY TO MYLIST LOOP READNEXT THING FROM MYLIST ELSE EXIT REPEAT ...does not work in D3? I think you are mistaken. My experience is that it works most excellently in D3, AP, and even R83- as a matter of fact, I think it probably works more consistently across all mv platforms than REMOVE. Are there any mv platforms that it doesn't work on? There is one caveat though: DYN.ARRAY must be @AM delimited (else you can CONVERT @VM TO @AM IN DYN.ARRAY first). /Scott Ballinger Pareto Corporation Edmonds WA USA 206 713 6006 --- 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] Text extraction.
I guess I was more focused on the REMOVE statement and let my fingers do the other typing. I'm not a LOOP REPEAT guy but rather a FOR NEXT guy, especially when knowing the boundary values. Not knowing the ending value of D caused me to use LOOP REPEAT which, given the wide variety of placements for the WHILE and UNTIL clauses, used the wrong one first. Since REMOVE (sans DCOUNT) doesn't know the end value, putting it in a FOR NEXT loop may require FOR I=1 TO I+1. I don't like using FOR I=1 TO I+1 as it mentally doesn't have a real ending. I'd rather DCOUNT a known ending, use LOOP UNTIL , REMOVE (with some more good experiences behind me) or use the EXIT clause. In my travels, the FOR I=1 TO I+1 usually has a test and a branch out of the loop which brings in single purpose statement labels which this forum frowns upon. BTW, i just tested REMOVE on D3 sans the AT clause and it didn't compile. That doesn't mean that it won't if another $OPTIONS clause is brought into the fray. Being an old-school guy, I got a little gun shy with all of the $OPTIONS and UDT.OPTIONS in my travels. Being a consultant and not a full time programmer or admin at my client's locations, I dare not fiddle with these settings. Every one of my clients has had their systems established by a VAR or someone else before me. I'm usually the current cook in the application kitchen. I don't need a phone call on Tuesday for some OPTION that I mis-set on Monday. Thanks Mark Johnson - Original Message - From: Ken Wallis [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Thursday, July 28, 2005 8:41 PM Subject: RE: [U2] Text extraction. Does this behave (misbehave) on u2 systems, ie be careful of the location of the UNTIL statement? Mark, that is the documented behaviour, it certainly isn't misbehaving. Yes, you have to be precise about when you terminate the loop, but surely a guy with your experience would always be precise about such things? BTW, is the AT clause something that D3 requires? UniData, UniVerse and jBASE certainly don't. Cheers, Ken --- 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] Text extraction.
Mark: Generally, the FOR/NEXT structure is used for looping where the loop count is known. If the loop count is unknown the LOOP/REPEAT structure should be used. Don't try to fit a square peg into a round hole. The REMOVE function is designed to traverse an array while preventing the next field read from having to start from the beginning of the array. When using small arrays, the need to use REMOVE is unnecessary. However, when using large arrays REMOVE is mandatory (this isn't true in UV). This is not true for D3, mvBase, and maybe UniData. So, use REMOVE when traversing large arrays and forget this FOR/NEXT looping BS. If you're only wanting to extract single valued arrays then READNEXT works just fine. D3 doesn't allow a SELECT to create a READNEXT list from an array so REMOVE is all D3 can use. As a result, REMOVE seems to be the generic statement to use under the specific circumstances. However, the syntax for D3 is different than the UV so one should keep in mind of the potential differences. Hope this helps. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Johnson Sent: Friday, July 29, 2005 4:33 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Text extraction. I guess I was more focused on the REMOVE statement and let my fingers do the other typing. I'm not a LOOP REPEAT guy but rather a FOR NEXT guy, especially when knowing the boundary values. Not knowing the ending value of D caused me to use LOOP REPEAT which, given the wide variety of placements for the WHILE and UNTIL clauses, used the wrong one first. Since REMOVE (sans DCOUNT) doesn't know the end value, putting it in a FOR NEXT loop may require FOR I=1 TO I+1. I don't like using FOR I=1 TO I+1 as it mentally doesn't have a real ending. I'd rather DCOUNT a known ending, use LOOP UNTIL , REMOVE (with some more good experiences behind me) or use the EXIT clause. In my travels, the FOR I=1 TO I+1 usually has a test and a branch out of the loop which brings in single purpose statement labels which this forum frowns upon. BTW, i just tested REMOVE on D3 sans the AT clause and it didn't compile. That doesn't mean that it won't if another $OPTIONS clause is brought into the fray. Being an old-school guy, I got a little gun shy with all of the $OPTIONS and UDT.OPTIONS in my travels. Being a consultant and not a full time programmer or admin at my client's locations, I dare not fiddle with these settings. Every one of my clients has had their systems established by a VAR or someone else before me. I'm usually the current cook in the application kitchen. I don't need a phone call on Tuesday for some OPTION that I mis-set on Monday. Thanks Mark Johnson - Original Message - From: Ken Wallis [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Thursday, July 28, 2005 8:41 PM Subject: RE: [U2] Text extraction. Does this behave (misbehave) on u2 systems, ie be careful of the location of the UNTIL statement? Mark, that is the documented behaviour, it certainly isn't misbehaving. Yes, you have to be precise about when you terminate the loop, but surely a guy with your experience would always be precise about such things? BTW, is the AT clause something that D3 requires? UniData, UniVerse and jBASE certainly don't. Cheers, Ken --- 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] Text extraction.
Who says us old dogs can't learn new tricks. I can think of prior D3 applications where I had a large DIM just to breeze through an indexed array. REMOVE has now been added to my bag of tricks. Thanks. - Original Message - From: Bill_H [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Friday, July 29, 2005 8:56 PM Subject: RE: [U2] Text extraction. Mark: Generally, the FOR/NEXT structure is used for looping where the loop count is known. If the loop count is unknown the LOOP/REPEAT structure should be used. Don't try to fit a square peg into a round hole. The REMOVE function is designed to traverse an array while preventing the next field read from having to start from the beginning of the array. When using small arrays, the need to use REMOVE is unnecessary. However, when using large arrays REMOVE is mandatory (this isn't true in UV). This is not true for D3, mvBase, and maybe UniData. So, use REMOVE when traversing large arrays and forget this FOR/NEXT looping BS. If you're only wanting to extract single valued arrays then READNEXT works just fine. D3 doesn't allow a SELECT to create a READNEXT list from an array so REMOVE is all D3 can use. As a result, REMOVE seems to be the generic statement to use under the specific circumstances. However, the syntax for D3 is different than the UV so one should keep in mind of the potential differences. Hope this helps. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Johnson Sent: Friday, July 29, 2005 4:33 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Text extraction. I guess I was more focused on the REMOVE statement and let my fingers do the other typing. I'm not a LOOP REPEAT guy but rather a FOR NEXT guy, especially when knowing the boundary values. Not knowing the ending value of D caused me to use LOOP REPEAT which, given the wide variety of placements for the WHILE and UNTIL clauses, used the wrong one first. Since REMOVE (sans DCOUNT) doesn't know the end value, putting it in a FOR NEXT loop may require FOR I=1 TO I+1. I don't like using FOR I=1 TO I+1 as it mentally doesn't have a real ending. I'd rather DCOUNT a known ending, use LOOP UNTIL , REMOVE (with some more good experiences behind me) or use the EXIT clause. In my travels, the FOR I=1 TO I+1 usually has a test and a branch out of the loop which brings in single purpose statement labels which this forum frowns upon. BTW, i just tested REMOVE on D3 sans the AT clause and it didn't compile. That doesn't mean that it won't if another $OPTIONS clause is brought into the fray. Being an old-school guy, I got a little gun shy with all of the $OPTIONS and UDT.OPTIONS in my travels. Being a consultant and not a full time programmer or admin at my client's locations, I dare not fiddle with these settings. Every one of my clients has had their systems established by a VAR or someone else before me. I'm usually the current cook in the application kitchen. I don't need a phone call on Tuesday for some OPTION that I mis-set on Monday. Thanks Mark Johnson - Original Message - From: Ken Wallis [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Thursday, July 28, 2005 8:41 PM Subject: RE: [U2] Text extraction. Does this behave (misbehave) on u2 systems, ie be careful of the location of the UNTIL statement? Mark, that is the documented behaviour, it certainly isn't misbehaving. Yes, you have to be precise about when you terminate the loop, but surely a guy with your experience would always be precise about such things? BTW, is the AT clause something that D3 requires? UniData, UniVerse and jBASE certainly don't. Cheers, Ken --- 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] Text extraction.
Mark, I usually split the difference and use: NEW=ABC:REC[15,LEN(REC)] It will always exceed (NEW=ABC:REC[15,100] could theoretically truncate) but it rarely exceeds by a ridiculous amount. - Chuck Nothing Exceeds Like Excess Barouch Mark Johnson wrote: Is there any downside to having a very large number that exceeds the actual length of a string to indicate the balance of the string in the [] function. I see: NEW=ABC:REC[15,LEN(REC)-15] versus NEW=ABC:REC[15,100] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Text extraction.
I used to do this thing that Chuck is advocating, but found that for very long strings, the LEN(..) function was expensive. So I always use 32200 for until the end and ensure that strings never go over this artificial 32K. (Of course, there are variations were such a thing to happen, but it doesn't happen at least in anything that I've designed.) Some platforms (Reality, maybe?) had the -1 option on substring extractions; I thought that was clever. Too bad it never caught on, or if it did, I didn't notice. -Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Key Ally Sent: Thursday, July 28, 2005 2:53 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Text extraction. Mark, I usually split the difference and use: NEW=ABC:REC[15,LEN(REC)] It will always exceed (NEW=ABC:REC[15,100] could theoretically truncate) but it rarely exceeds by a ridiculous amount. - Chuck Nothing Exceeds Like Excess Barouch --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Text extraction.
On uniVerse to enable -1 as meaning till the end of the string use: $OPTIONS REAL.SUBSTR mysub=longstring[starpos,-1] If you want to disable the -1 as meaning till the end of string, use $OPTIONS -REAL.SUBSTR _ I reject your reality and substitute my own - Adam Savage Glenn M. Herbert - Connectivity Development Engineer Information Integration Solutions, IBM Software Group 50 Washington Street Westboro, MA 01581 508-599-7281 direct Some platforms (Reality, maybe?) had the -1 option on substring extractions; I thought that was clever. Too bad it never caught on, or if it did, I didn't notice. -Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com -Original Message- --- 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] Text extraction.
Oh yes, I forgot to add that if you use the $OPTIONS REAL.SUBSTR you can also use other negative values as the second substring parameter, which then indicates that you want to start the substring extraction from your starting point but extract only until the Xth character from the end. For instance: 0001 $OPTIONS REAL.SUBSTR 0002 X=1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ 0003 PRINT A: :X[11,-1] 0004 PRINT B: :X[11,-5] will result in: A: ABCDEFGHIJKLMNOPQRSTUVWXYZ B: ABCDEFGHIJKLMNOPQRSTUV _ I reject your reality and substitute my own - Adam Savage Glenn M. Herbert - Connectivity Development Engineer Information Integration Solutions, IBM Software Group 50 Washington Street Westboro, MA 01581 508-599-7281 direct Some platforms (Reality, maybe?) had the -1 option on substring extractions; I thought that was clever. Too bad it never caught on, or if it did, I didn't notice. -Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com -Original Message- --- 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] Text extraction.
You can still do the reality -1 option on UV reality flavor. I've suggested in the past (Ardent? Vmark? Who remembers?) to allow it on other flavors as well, to no avail. -Dianne Kevin King wrote: I used to do this thing that Chuck is advocating, but found that for very long strings, the LEN(..) function was expensive. So I always use 32200 for until the end and ensure that strings never go over this artificial 32K. (Of course, there are variations were such a thing to happen, but it doesn't happen at least in anything that I've designed.) Some platforms (Reality, maybe?) had the -1 option on substring extractions; I thought that was clever. Too bad it never caught on, or if it did, I didn't notice. -Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Key Ally Sent: Thursday, July 28, 2005 2:53 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Text extraction. Mark, I usually split the difference and use: NEW=ABC:REC[15,LEN(REC)] It will always exceed (NEW=ABC:REC[15,100] could theoretically truncate) but it rarely exceeds by a ridiculous amount. - Chuck Nothing Exceeds Like Excess Barouch --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Text extraction.
Glenn, I didn't know about that $OPTIONS setting! Thanks so much for pointing it out!! Too bad UV support didn't mention it to me ages ago when I had called them about it. -Dianne Glenn Herbert wrote: Oh yes, I forgot to add that if you use the $OPTIONS REAL.SUBSTR you can also use other negative values as the second substring parameter, which then indicates that you want to start the substring extraction from your starting point but extract only until the Xth character from the end. For instance: 0001 $OPTIONS REAL.SUBSTR 0002 X=1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ 0003 PRINT A: :X[11,-1] 0004 PRINT B: :X[11,-5] will result in: A: ABCDEFGHIJKLMNOPQRSTUVWXYZ B: ABCDEFGHIJKLMNOPQRSTUV _ I reject your reality and substitute my own - Adam Savage Glenn M. Herbert - Connectivity Development Engineer Information Integration Solutions, IBM Software Group 50 Washington Street Westboro, MA 01581 508-599-7281 direct Some platforms (Reality, maybe?) had the -1 option on substring extractions; I thought that was clever. Too bad it never caught on, or if it did, I didn't notice. -Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com -Original Message- --- --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Text extraction.
No. Because of how strings are implemented within universe, consisting of a structure containing a length value and a pointer to the string, a substring operation is simply an operation (nicely termed 'mid') that returns a new string structure with its pointer at your desired starting point, and setting the length to either the value you passed in or, if that exceeds the length of the original string minus your starting point plus 1, the length is set to that value. When that new string structure pointer is placed into the runtime variable table, memory is allocated and copy of the string is saved and a strlen done (or if NLS some equivilent), creating your new variable. By the way, a len() operation in universe is VERY fast, as it does not do a strlen() or any type of count operation; it simply returns the length value of the string structure set at definition time. Using a len() as the second parameter is probably microseconds faster since the subtraction +1 doesn't have to get done; IMO I don't think it makes much difference. _ I reject your reality and substitute my own - Adam Savage Glenn M. Herbert - Connectivity Development Engineer Information Integration Solutions, IBM Software Group 50 Washington Street Westboro, MA 01581 508-599-7281 direct Is there any downside to having a very large number that exceeds the actual length of a string to indicate the balance of the string in the [] function. I see: NEW=ABC:REC[15,LEN(REC)-15] versus NEW=ABC:REC[15,100] Just curious. Thanks. --- 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] Text extraction.
Mark, I know you usually look for cross platform solutions, so this may be a UVism but how about NEW=ABC:REC[15,-1] Then you have no constant limits to worry about. Craig --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Text extraction.
Thanks. I'll try this and get back with the MCD and MvBase results. D3 didn't like it. Speaking of D3, I tried the REMOVE that was so popularly offered on this forum. The AP-Pro and D3 manuals identically suggest it but it didn't compile (BASIC or compile). I hate to venture into this arena but someone offered to use $OPTIONS EXT to get the REMOVE to work on D3. Without the $OPTIONS, it doesn't work. I found a caveat though: Program 1 X= ; FOR I=1 TO 20 ; XI=I ; NEXT I L=0 LOOP REMOVE A FROM X AT L SETTING D UNTIL D=0 DO PRINT X REPEAT prints 1-19. Program 2 X= ; FOR I=1 TO 20 ; XI=I ; NEXT I L=0 LOOP REMOVE A FROM X AT L SETTING D PRINT X UNTIL D=0 DO REPEAT prints 1-20 as expected. Apparently the value of D gets set to the terminator when it extracts the final value. I'll have to note this else I'll get expected results. Does this behave (misbehave) on u2 systems, ie be careful of the location of the UNTIL statement? Thanks. - Original Message - From: Craig Bennett [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Thursday, July 28, 2005 7:40 PM Subject: Re: [U2] Text extraction. Mark, I know you usually look for cross platform solutions, so this may be a UVism but how about NEW=ABC:REC[15,-1] Then you have no constant limits to worry about. Craig --- 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] Text extraction.
Does this behave (misbehave) on u2 systems, ie be careful of the location of the UNTIL statement? Mark, that is the documented behaviour, it certainly isn't misbehaving. Yes, you have to be precise about when you terminate the loop, but surely a guy with your experience would always be precise about such things? BTW, is the AT clause something that D3 requires? UniData, UniVerse and jBASE certainly don't. Cheers, Ken --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Text extraction.
Is there any downside to having a very large number that exceeds the actual length of a string to indicate the balance of the string in the [] function. I see: NEW=ABC:REC[15,LEN(REC)-15] versus NEW=ABC:REC[15,100] Just curious. Thanks. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Text extraction.
Mark Johnson wrote: Is there any downside to having a very large number that exceeds the actual length of a string to indicate the balance of the string in the [] function. I see: NEW=ABC:REC[15,LEN(REC)-15] versus NEW=ABC:REC[15,100] Not that I know of, but anybody who's had to fix a bug caused by a prior programmer using this technique and underestimating what 'a very large number' should be, will prefer to see the former to the latter. Personally, I prefer NEW=ABC:REC[15,LEN(REC)] Since it guarantees that you get the right hand end of the text without an unnecessary calculation, and LEN(REC) is implicitly known by the run machine without needing to count bytes. Cheers, Ken --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
