Re: UNSTRING performance issue
- From: "Chris" <ctaliercio@xxxxxxxxx>
- Date: 29 Nov 2005 09:04:13 -0800
Sorry doc - trust me - this isn't homework. More like an old dog
looking for a new trick. Then again, by COBOL standards, at 33 I may
well be a young whipper-snapper. But I've been coding COBOL for quite
some time now - 10+ years and counting. You'd probably find some of my
other posts/contributions a bit more intriguing than this one.
To clarify, in my world, the nth field is the field following the
(n-1)th delimiter. So in your your example string:
VAL1,,VAL2
VAL2 is actually the 3rd field, with the 2nd field containing a "null"
value.
The only reason I posed this question is because I actually found a
source in my library where the original author has defined JUNK-x
fields in the WORKING-STORAGE section in order to "pad" his unstring
statements. Instead of looking for a better way to get to the 59th
value in a set, that person actually has declared JUNK-01 all the way
up to JUNK-58 (all as pic x(1) variables). The unstring statement is a
beast to behold, consuming over 60 lines, since he enumerates each
JUNK-XX field on its own line.
To my way of thinking, while the code works, this is not exactly "best
practice." In scenarios like this, I had always used code snips like
the one I posted here. I was just wondering if this was going to garner
the optimal performance or if the original author knew something I did
not. So - I put the question out there for folks with more knowledge
than myself:
Thanks for the suggestion, and your code snip makes perfect sense.
Chris
docdwarf@xxxxxxxxx wrote:
> In article <1133276339.806234.154820@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
> Chris <ctaliercio@xxxxxxxxx> wrote:
> >Given a delimited string of variable length (string-variable), suppose
> >you are interested in the nth value in the string.
>
> Question of definition, please. Given the comma-delimited string:
>
> VAL1,,VAL2
>
> ... are you calling VAL2 the second or third value in the string?
>
> >
> >I'm currently using the following solution:
> >
> >MOVE "," TO delimiter-variable
> >MOVE 1 TO string-pointer
> >
> >PERFORM n TIMES
> >
> > UNSTRING
> > string-variable DELIMITED BY delimiter-variable
> > INTO
> > string-field
> > WITH POINTER
> > string-pointer
> > ON OVERFLOW
> > SET unstring-error TO TRUE
> > EXIT PERFORM
> > END-UNSTRING
> >
> >END-PERFORM
>
> Wow... someone has done their own homework!
>
> >
> >
> >Obviously, the larger the string, the slower the performance of this
> >command.
> >
> >I'm wondering if there is a faster way to do this that I am as yet
> >unaware of?
>
> Depends on the compiler/platform, of course... but off the top of my
> pointy little head, to find the data following the nth delimiter:
>
> Perform Varying Sub1 from 1 by 1
> Until All-Done
> If Variable(Sub1:1) = delimiter
> Add 1 to Delims-Found
> Evaluate True
> When Delims-Found = n
> Perform Varying Sub2 from Sub1 by 1
> Until Variable(Sub2:1) = delimiter
> Or Sub2 > (Length of Variable)
> Continue
> End-Perform
> Subtract 1 from Sub2
> If Sub2 > 0
> Move Variable(Sub1:Sub2) To Another-Field
> Else
> PERFORM B1520-EMPTY-FIELD-RITUAL THRU B1520-EFR-EX
> End-Evaluate
> End-If
> End-Perform
>
> ... or something like that, the errors in my extemporaneous coding should
> be obvious.
>
> DD
.
- Follow-Ups:
- Re: UNSTRING performance issue
- From: HeyBub
- Re: UNSTRING performance issue
- From:
- Re: UNSTRING performance issue
- References:
- UNSTRING performance issue
- From: Chris
- Re: UNSTRING performance issue
- From:
- UNSTRING performance issue
- Prev by Date: Re: UNSTRING performance issue
- Next by Date: Re: UNSTRING performance issue
- Previous by thread: Re: UNSTRING performance issue
- Next by thread: Re: UNSTRING performance issue
- Index(es):
Relevant Pages
|