Re: UNSTRING performance issue

Chris wrote:
> 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:

Let's think about "best practice."

I suggest the original code (JUNK-01 thru JUNK-58) is superior in
performance since
a. There's no loop overhead, and
b. There's only one instance of UNSTRING initialization

The original code has two disadvantages, though:
1. It's ugly, and
2. I can't think of another, but I'm sure there is one.

I, personally, would not have used JUNK-01 through JUNK-58. I'd have used:

UNSTRING MY-DATA DELIMITED BY ',' INTO
JUNK
JUNK
JUNK
JUNK
...
MY-VALUE.

thereby saving another 57 bytes of core/ram.


.