| William M. Klein 2004-09-16, 3:55 pm |
| Robert,
We have been thru this before. Some compiler vendors continue support for
"undocumented extensions" and some don't. Any programmer relying on such, seems
silly to me (but YMMV).
For an example of exactly HOW many undocumented extensions IBM dropped support
for, see:
http://publibz.boulder.ibm.com/cgi-...IGY3MG20/3.3.14
and
http://publibz.boulder.ibm.com/cgi-.../IGY3MG20/4.1.6
***
Unlike IBM, Micro Focus often (not quite always) adds new directives, cf
OLDNEXT-SENTENCE
and several other OLDxxxx directives
Anyone who assumes that Fujitsu will always support their current (undocumented)
SET ADDRESS OF (not conforming to ISO 2002) syntax, will EVENTUALLY find out if
this was or wasn't a safe assumption.
--
Bill Klein
wmklein <at> ix.netcom.com
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:2tg1k09dhunkm7r4408ahkr13540j8388i@
4ax.com...
> On 8 Sep 2004 23:13:09 -0700, riplin@Azonic.co.nz (Richard) wrote:
>
>
>
> SET ADDRESS is unsupported but implemented by Fujitsu.
>
> I really doubt compiler companies will delete extensions that once
> worked. When Micro Focus or IBM releases a 2002 compiler, do you think
> we'll have to rewrite SET ADDRESS to BASED-STORAGE?
>
>
> One cannot insert a row between two existing ones in a Cobol table.
>
>
> Try doing that on an unsorted table. While you're sorting the table,
> I'll build a tree. Never mind, it's already built. I'll do the lookups
> in the unbalanced tree while you're sorting. Want to see it again?
> I'll do them a second time while you're STILL sorting.
>
>
> Sorting is inherently complex too. We hide that from the user by
> putting the logic in a library called by the SORT verb. The same could
> have done for lists.
>
> In the old days, structures natively supported by the language, such
> as tables, had a simplicity advantage over structures we had to manage
> ourselves. OO changed the balance. We can now create types and
> supporting methods that are nearly as easy to use.
>
> Someone said 'Two things would sicken the average citizen: the inside
> of a slaughterhouse and seeing how government actually works.' We seem
> to have found a third in data management algorithms.
>
>
> The principle is MISS -- Make It Simple, Stupid .. even if it isn't.
>
>
> A pointer to the next entry in a list is no more complex than adding 1
> to a subscript. In fact, it's simpler. I don't have to multiply by the
> size of an occurrence to find it.
>
>
> Do you have evidence? I posted code that did it both ways and measured
> total build and lookup time to be:
>
> MF table sort, search all 5.1
> tree, lookup (unbalanced) 2.6
> tree, balance, lookup 2.6
>
>
> I didn't say everyone; I said simplicity advocates.
>
>
> No, I posted that for people wanting to learn how to program. Others
> will continue doing it the slow way until someone hands them an
> easy-to-use package.
>
>
> In that case, the lookup could switch to binary chop. I posted a demo
> that sorted by rotating the tree until everything was on the right,
> then did lookups with binary chop.
>
> tree, to table, search all 2.9
>
> If inputs had been in sequence, rotation would have stopped after one
> pass. Time would have been 1.3.
>
>
> Random inputs do not produce a well-balanced tree. One has to
> unbalance it until everything is on the right (or left), in other
> words sort the entries. Only then can a balanced tree be built.
>
>
> 'I tried that once and ran into problems. It follows, therefore, that
> nobody else should be allowed to use it.' I once worked for a manager
> who set shop standards by that logic. She wouldn't allow Cobol SORT
> because she had trouble with it ten years earlier.
>
>
> See above. Twice the speed is not insignificant. The specific case was
> 50,000 random 30-byte keys, which seems typical of everyday use.
>
>
> It would be the same, because tree search would detect that and switch
> to binary chop.
>
>
> It is a prelude to managing more complex structures in databases. You
> have to crawl before you can walk.
|