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

On Thu, 13 Mar 2008 02:12:39 +1300, "Pete Dashwood"
<dashwood@[EMAIL PROTECTED]
>
wrote:

>"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 ****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?
>
>No comment?

I said Micro Focus was wrong in the Myth Busters thread, six months ago. I
substantiated
each point with the evidence of at least one timing test. 

Belief trumps evidence in the land of Cobol. I mentioned it now not to
retread the same
ground but to use those faith-based rebuttals as evidence that some
(most?) Cobol
programmers are opposed to dynamic structures. 

Now that the shoe is on the other foot, I'm wrong again. 

This is like arguing with your wife. You can't win; no matter what you say
is wrong.
That's because the argument is not about facts, it's about feelings. 

At least wives don't claim to be professional.

>>>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 SIZE of the array depends on the count field. The LENGTH of the array
is the maximum. 

Suppose you're flying a kite and someone asks the size of the tether
string. You say 100
meters. Then he asks for the length of your tether string. You say 1,000
meters. He says
you're wasteful, why are you spending 1,000 meters of string to fly a kite
100 meters out?
You say it's more efficient to use one string for all kite flights (under
1,000 meters)
than to have a 100 meter string, a 200 meter string, ... and a 1,000 meter
string. The
total ensamble would consume 5,500 meters of string. 

Being a business graduate, he says you could save string expense by
RENTING a string of
the required length and returning it when not in use. Even though renting
costs twice as
much as buying, you're not wasting string. 

Thus was born the idea of contract programmers. Expense is doubled but no
one is idle.

On the other hand, if you're in the business of selling string or
computers, you want to
encourage fixed partitions and preallocation, because it sells more
hardware. IBM are the
experts on this. I once saw a survey of mainframe disk utilization that
showed 80% of the
space was unused due to fixed allocation at about six levels -- disk,
space group, file,
FBA, fixed length record padded with filler, fixed length fields padded
with spaces.

I wonder how parking lots at IBM are managed. Do you suppose each parking
space has a
person's name?

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

Micro Focus has little standard balloons on every clause.  

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

I've been doing it heavily, all the time, for over twenty years. 

1. call 'malloc' using by value length of FOO returning mem-pointer 
(every compiler & OS)

2. call 'CBL_ALLOC_MEM' using mem-pointer, by value length of FOO, flags 
(Micro Focus)
2a. call 'M$ALLOC' using length of FOO, mem-pointer  (Acucobol)

3. allocate FOO returning mem-pointer

4. invoke FOO "new" returning object-pointer

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

Compute log2(length) to get the number of looks your way. Compute
log2(size) to get the
number of looks with ODO. If your calculator doesn't have log2, use ln(x)
* 1.44.

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

As I said, it's about feelings.

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

That's because you're hitting the database to look up common reference
codes instead of
searching for them in tables.  <ducking>