Re: J4 - presentation/discussion on "Future of the COBOL Standard"

On Wed, 12 Mar 2008 17:01:25 +1300, "Pete Dashwood"
<dashwood@[EMAIL PROTECTED]
>
wrote:

>"Robert" <no@[EMAIL PROTECTED]
> wrote in message 
>news:f6eet3depq6ugth6br7r2mk1hd5u9uiiqk@[EMAIL PROTECTED]
>> On Tue, 11 Mar 2008 17:50:02 GMT, "William M. Klein" 
>> <wmklein@[EMAIL PROTECTED]
> wrote:
>>
>>>"Robert" <no@[EMAIL PROTECTED]
> wrote in message
>>>news:m1pbt3hf9l197putsqlr2pvr1iccpgv7ka@[EMAIL PROTECTED]
>>>> On Mon, 10 Mar 2008 17:12:04 -0600, "Frank Swarbrick"
>>>> <Frank.Swarbrick@[EMAIL PROTECTED]
>
>>>> wrote:
>>>>
>>><snip>
>>>
>>>> The average Cobol programmer has avoided Occurs Depending On for 22 
>>>> years.
>>>>
>>>
>>>As usual, Robert's claim for what the "average COBOL ****gramme" does or

>>>doesn't
>>>do is based on his rigourously applied research method, i.e. "it seems
to 
>>>me -
>>>that of those programs and programmers that I have seen, that ..."
>>
>> When ODO comes up in this forum, as it did 3 years ago and 6 months ago
in 
>> my Myth Busters
>> thread, some here said it should not be used because it is too slow
(even 
>> when faced with
>> contrary evidence)  or because it adds 'unnecessary complexity'. The
Micro 
>> Focus Server
>> Express performance tips manual says it is slower; an IBM manual you 
>> linked to says the
>> same.
>
>So, are you saying these manuals are wrong?
>
>I don't use it because I don't believe it saves anything and it just adds

>overhead (although I realy don't care about that) and complexity
(although I 
>really don't care about that either... :-)). Basically, it promises to
save 
>memory, then goes and allocates the largest possible space anyway. THAT'S

>why I REALLY don't like it... it simply fails to deliver what it
promises. 
>:-) (Failure to deliver, usually pisses me off... :-))

No, it doesn't promise to save memory. The standard says working-storage
is allocated
statically. Actually, it can save memory, but only if YOU dynamically
allocate the ODO
structures. This seldom comes up in ODO discussions. I mentioned it when I
talked about a
parser creating linked lists of variable length lines and words. 

>Now, your point about sorts on ODO arrays being faster is an interesting 
>one, but, as I have never used an ODO array in memory and therefore have
no 
>need to sort it, for me, that's a teeny bit irrelevant... I don't sort
fixed 
>length arrays either; instead, I load them in sequence and use SEARCH ALL

>(if they're large) or just SEARCH if they're small. Easy, no messing,
does 
>the job, works for me.

Your SEARCH ALLs would run faster if the arrays were dimensioned with ODO
rather than
fixed length. What part of speed do you find complex?

>I simply don't understand why you are so fired up in sup****t of ODO. What
am 
>I missing, here?

You are missing the point of the thread, which was acceptance of
dyamically sized
structues in the next Cobol standard. 

>> Manuals fail to point out that ODO makes SEARCH ALL 10% faster for
typical 
>> (2^10) table
>> size. Assuming the table is half full, the difference is 1 - (log2(n) /
(1 
>> + log2(n))).
>>
>
>(Yawn)... so I should use ODO to save a few milliseconds when I need to
sort 
>an array?

>But I DON'T need to sort an array... ever. And if I did I'd take the
hit...

I didn't say anything about sorting an array. 

>> Files? I thought files were replaced by databases years ago. Rows don't

>> contain arrays.
>
>No they don't. But they can vary in length, WITHOUT needing ODO...
VARCHAR 
>columns are implemented the way ODO SHOULD have been... transparently to
the 
>user.

They are implemented the same way BASIC did it 40 years ago. Transparency
depends on the
garbage collector.