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

"Charles Hottel" <chottel@[EMAIL PROTECTED]
> wrote in message 
news:13tjhkj7pvme732@[EMAIL PROTECTED]
>
> "Robert" <no@[EMAIL PROTECTED]
> wrote in message 
> news:cm4ht3t7o5mpec667tfe24geucbtor16ut@[EMAIL PROTECTED]
>> 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>
>>
>
> Did you ever tilt at windmills in an earlier reincarnation circa 1600?
>

I seem to hazily recall a little fat guy who was a barber...followed me 
around... and there was this hot chick... Dulcie something... er... no.

Besides, If I had tilted at windmills, they would've stayed tilted... :-)

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