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

"Robert" <no@[EMAIL PROTECTED]
> wrote in message 
news:38kft3t3h52mm32b1vekgqe1qu98l7l1la@[EMAIL PROTECTED]
> 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 porgramme" 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?
>>

No comment?

>>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.

Er...excuse me, but I think it does. It says the size of the array DEPENDS

ON the count field. But it doesn't. The size of the array is always the 
maximum possible.

> The standard says working-storage is allocated
> statically.

I have yet to see an implementor's manual that references the standard. As

implementor's manuals are what programmers normally use, whatever the 
standard says is really irrelevant.

>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.

I know of no way in COBOL (apart from CICS and Assembler GETMAIN calls on 
IBM mainframes) that can DYNAMICALLY allocate storage. So how exactly am I

supposed to dynamically allocate these ODO structures?
>
>>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.

I doubt it and would need to see proof.  And, to be brutally frank, I
really 
don't care... :-)

ODOs must be calculated at run time (even for fixed references); fixed 
length can be calculated at compile time, for fixed references. I would 
agree there probably isn't much to choose between variable references, but

I'd still have to code that awful ODO and it is UGLY!!!! :-)

Even then, if it saves a few milliseconds but I have to code ODO, that 
solution is not for me...


>What part of speed do you find complex?

:-)

Given that I have actually optimised existing applications and been paid 
serious money for making them run many times faster than they did 
previously, probably not much. However, I am not obsessed by processor
speed 
in applications which spend most of their time waiting for IO to
complete...


>
>>I simply don't understand why you are so fired up in support 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.

OK, if you say so... :-)  I really have no comment on that so will butt
out 
at this point.

Pete.
-- 
"I used to write COBOL...now I can do anything."