in reply to RE: RE: Intended use and unintended use. An insight into design. (Continued)
in thread Intended use and unintended use. An insight into design.

Wow. I've never seen anyone beat a horse to death with an analogy :)

The problem with analogy, of course, is that it can be confused with Truth when it is intended simply for illustration.

Considering the tremendous overhead involved with getting a mainframe up and running, why would any new company throw away the car keys and use COBOL? For an established company that is already entrenched in COBOL, the "overhead" is a sunk cost. Converting to different languages would involve an analysis of future costs and those costs may be unsustainable.

To slightly skew the analogy, how many of us have bought a new car, had it turn into a beater over the years and have spent so much money fixing it that we can't afford a better car, but know we need one?

JanneVee, I'll make you a deal: if you can show me a cost-effective reason why any new company would use COBOL, I will admit my error and tell everyone how you have humbled me with your wisdom :)

  • Comment on RE: RE: RE: Intended use and unintended use. An insight into design. (Continued)

Replies are listed 'Best First'.
RE: RE: RE: RE: Intended use and unintended use. An insight into design. (Continued)
by JanneVee (Friar) on Jun 23, 2000 at 02:30 UTC
    I'll make you a deal: if you can show me a cost-effective reason why any new company would use COBOL, I will admit my error and tell everyone how you have humbled me with your wisdom :)

    I don't believe in me being right or you being wrong. It is seeing things in different ways.

    But to give you an example of why a new company would consider a "new" COBOL solution cost-effective! When it comes to companies. Quite often they aren't isolated, they have to interface their system with other systems, to avoid breaking the "shop standard consistency" of their partner(let say an old dinosaur company!). It usually means that they are better of augmenting the old system with their own system (use cobol on their own machines to interface).

    Here is another example... A new Consulting company that maintains old COBOL solutions, to train their personel they let them build a system for them in COBOL. "A cost-effective training implementation"!

[reply]
      Your first example: whenever I have had to interface data with another company, the only thing I have had to worry about is the format of the data. The languages were not important. The only reason I can think of for the new company to have to switch to COBOL would be if they were bought out by the other company and forced to work on the same machine. Even when I've seen this happen (in my last company, we had four states merge into one), it has still been a matter of accepting a standard for the format and sticking to it (I wish Micro$oft understood this). Then, when we developed new systems, they often were not in COBOL (unless we had a dinosaur leading the team).

      As for the second example, that one is trickier. Maybe my challenge to you should have specified "a new company that's not performing mouth-to-mouth on a stegosaurus". I may be forced to sing your praises simply because I worded my "deal" wrong.

      In any event, I see that both of your examples are dependant upon current implementations of COBOL. If a company is starting from scratch, why would they use it?

[reply]
        I may be forced to sing your praises simply because I worded my "deal" wrong.

        Actually i don't see such a reason. Why a new company would want to implement anything new in Cobol. Because I wouldn't want to implement something from the begining in Cobol. Unless I recieved an old mainframe and had to build a new system for it. The likeliness of that happening. 0 % ...

        whenever I have had to interface data with another company, the only thing I have had to worry about is the format of the data. The languages were not important.

        How about the indexed fileformats? Due to the lack of standard of these wouldn't you have to at least find out the standard of the fileformat of the Cobol they are using?

[reply]

In Section Meditations