Alan Cox wrote:
quoted text
>> It's not necessarily that simple.  It might be for KFC and Dominoes, but
>> for others, SCO is not the complete story.  Many legacy systems are
>> written in COBOL, and must pay a per-seat licence for that on top of the
>> per-seat licence for UNIX.  It is these systems that are most attracted
>> towards SCO compatibility.
>>     
>
> And they mostly use microfocus cobol which is available on Linux
Or RM Cobol, which is also available on Linux.  Both of these require
significant expense in new licences.

quoted text
> or they do a quick port to the fujitsu cobol->java vm translator.
>   
I don't know of this thing, but I have looked, on behalf of a colleague,
for tools that can compile his existing COBOL source, and found only
partial solutions (i.e. found nothing.)

quoted text
> There are people in this community who deal day in and day out with
> migrations. I don't hear a whisper of concern from those I deal with
> about losing iBCS. 
Well, I'm whispering:  The cost is that something desirable but
incomplete would be removed.  While it's there it's a constant source of
irritation to those in the know.  Once removed it can be forgotten.  So
the cost is really that iBCS2 compatibility becomes less likely.  What's
the benefit in removing it?  Up to 20 cycles per exec?  That's nothing.
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/