• SwordfishBob (unregistered) in reply to l1fel1ne

    I can understand some hesitance to rewriting, though it depends on the size/complexity of the initial problem vs workload in keeping it intact.  See JoelOnSoftware.com for an essay on the problems of rewrites.
    I've worked (a while back) for a gov't research organisation where I
    - rewrote a desktop application (C++ with terrible text-based UI into FoxPro 2.6 with a UI that was said to be impossible prior to FoxPro 3.0)
    - ported a smallish simulation/forecast model from Fortran to C (and found & corrected a bug in the previous Vax to MS FORTRAN porting effort)
    - was not allowed to attempt anything with a larger, more complex model which also was in FORTRAN.

     There was much demand to use this latter model is a range of situations and other applications, but it was not easy to hook into while keeping it as a single lump.  Instead of being "an implementation" of a mathematical model, it was actually the only existing expression of that model.  Some years before me, a bunch of CS folk took on a complete rewrite using AI/KBS techniques, but made a complete mess of it and the resulting program was so slow it was unuseable.  And they wasted a lot of time and money while telling everyone this thing would be great.  It wasn't.  So the idea of rewriting/refactoring, or using OO techniques on this model, turned into a dirty word.

  • CodeMonkey (unregistered)
    jdieter:

    A company that dosen't want to rewrite all their code every 2 years?  They really think you can write a program that will "still work next year"???? Impossible. Does anyone have a piece of code still running that hasn't been recompiled in years?

    I'm a developer in the Automotive space and even compete with morons like these.  I actually do have code that is still running over 6 years later that the dealers won't let go of.  Our DOS product was developed over 9 years and 40 of the 2000 dealers just won't upgrade to our new windows product...it works just great for them.  I'm not sure if I could find the compiler floppies! 

     Sounds like UCS to me.  Reynolds and ADP have been Unix Pick platform for decades...funny thing is UCS just acquired Reynolds! Misery loves company.

    CodeMonkey

     

  • (cs)

    Wow!  I'm amazed at all the responses to this... This company was definitely stuck in the dark ages... For the record, they did take SOME poetic license with some of the details.  For example... all the changes, the compiler, the emulator, the debugger... really happened all around the same time... And I don't think I specified exactly which type of computer they used... I don't quite remember myself, I worked on Windows boxes...  Anyway... say what you will about it being a bad place to work, but when you've been out of work for a while and you need experience, any port in a storm, and all... They didn't even pay decently.  Oh, and it wasn't all that slow, actually... amazing what you can do with an up-to-date processor and 30 year old code.

  • (cs) in reply to codewolf
    Anonymous:

    The thing that confounds me is when someone intetionally makes a windows program that looks and acts exactly like a terminal program.  We had a group where I work (most of them do not work here anymore) that were given the challenge of updating our finantial software.  They were all long time COBOL programmers that knew how the old system worked.  They created a Visual Basic 5 app that looked and worked exactly like the prevoius program except it was slower.  That program was never released.  A more usefull program was created via ASP(vbscript,javascript,HTML) and has hardly any complaints.

     I have to wonder how much per year the company here was charging for maintence contracts and how many customers were still being retained for this software.  If they were getting mega bucks for maintence then it might have paid for them to do what they did.  I can see though the day when half of their customers tell them they do not want to renew the maintence.

    Why would the customers not want to renew the maintenance? Because of the ugly UI? Ask some users. The last thing they want is a new UI as long as the existing one allows them to work quickly. Might be ugly as hell and ignoring all Windows UI conventions, but that's what they've worked with over the last 20 years, they know it by heart and every change means discomfort.

    The real problem is that you can hardly win new customers with such an ugly beast, so your customer base will be slowly but steadily decreasing. 

  • (cs) in reply to tanisha
    Anonymous:

    The real WTF (Tm) here is that people here think they are doing something *wrong*.

     The assumption is that it would be cheaper and easier to maintain the system if it was rewritten to work on todays computers. It also may likey sell more copies if the program had an easy to use interfaces.

     We aren't jumping up and down saying they should be using the the latest and greatest tools, just to use the new tools. We are saying they are wasting their time and money trying to maintain an old obsolete system.

     

    The real WTF is regular posters entering a CAPTCHA

  • vid (unregistered)

    One of David's first challenges was COBOL's event model, or, more accurately, its lack of one. In standard Windows programming, when the user clicks on a button or does just about anything else, Windows raises an event to tell the application what happened. In COBOL programming, the application periodically asks if the user did an action. They were able to work around this by creating an "action queue" that allowed COBOL to see what happened and respond accordingly.

    This is not true. Windows creates message queue for all windows, and application periodically asks if there is some message for some window in queue. Typical way is to send this message to handler of window then.

  • Darin (unregistered) in reply to mraymondus

    mraymondus:
    Too funny.  I thought my previous employer was the only company on the planet still doing new product development in a dying language and on a proprietary platform that is more than 10 years old.   Reading this kind of stuff really makes my day :)

    I think that if you talk to programmers under 30 about this stuff, they'll almost universally say "WTF?", but if you talk to programmers over 50 there's a much higher chance to hear them say "yeah, been there, seen that."

  • Froot (unregistered) in reply to zip

    >  But how does this company remain profitable?

     My guess: By not gratuitously rewriting software that works.
     

  • (cs) in reply to Alexis de Torquemada
    Alexis de Torquemada:
    Actually caps lock on Microsoft Windows is not even a TRUE caps lock, it's more of a SHIFT LOCK which means when you try to type numbers when caps lock is ON, what you ACTUALLY GET is PUNCTUATION - can you BELIEVE IT?!!!!!!!!!

    nO i DON'T BELIEVE IT. I CAN TYPE NUMBERS JUST FIND WITH CAPS LOCK ON 1234567890

    Don't blame Microsoft Windows because you had a cheap keyboard.

  • (cs) in reply to Alexis de Torquemada
    Alexis de Torquemada:
    Actually caps lock on Microsoft Windows is not even a TRUE caps lock, it's more of a SHIFT LOCK which means when you try to type numbers when caps lock is ON, what you ACTUALLY GET is PUNCTUATION - can you BELIEVE IT?!!!!!!!!!

    nO i DON'T BELIEVE IT. I CAN TYPE NUMBERS JUST FIND WITH CAPS LOCK ON 1234567890

    Don't blame Microsoft Windows because you had a cheap keyboard.

  • Cheong (unregistered)

    But has anyone advise their management to send people to write a COBOL compiler for Windows (Much like MS Foxpro for Windows v2.5 to MS Foxpro for DOS v2.5)

     I think it'd be easier to write efficient and debugable code that way. And best of all, they don't need to change the code that "No need to Change It!".
     

    Captcha: clueless (What a coincidence!) 

  • john (unregistered) in reply to John Hensley

    Lookee here, GNU COBOL: 

    http://www.gnu.org/software/cobol/cobol.html

    Port, refactor to support common data formats, build a "service" front end, and implement the GUI in Java, .net, HTML, or some other relatively contemporary technology.  Say what you will about COBOL - it's not intended for writing "fun" or "cool" software.  It's for money.

  • Adrian P (unregistered)

    My head just exploded.

  • (cs) in reply to sinistral
    sinistral:

    What a minute.  The IBM System/3 series was supplanted by the System/32, System/34, System/36, System/38, AS 400, and now iSeries.  You can take binaries that ran on (at least as far back as) a System/36 and run it on an iSeries.  I would think that IBM would help with this... it's not even porting.  It's just recompiling on the new machine.  In fact, the iSeries, which uses Power PC processors, has VM technology that's like what people are doing with Rosetta on Mac or VMWare on Win/Linux machines, so that the binaries run without problem.  If there's one thing that IBM is good for, it's backward compatibility.

     

    I'm not calling 'fake' on the submitter of the story, not in the least.  I just don't understand how the IBM guys couldn't make the company understand that they could provide the same services that they hired all their "Smart People" to do, and better, using newer IBM hardware. 

     

    [Note from Alex: This was before David's time, but from what he said, the point of the emulator was so that they did not have to recompile and could use their old S/3 binaries]

    Maybe the point was that dealerships weren't willing to buy an AS 400 to replace their ancient System/3 when they had a bunch of perfectly decent 286s with Windows 3.1 sitting around. I'm not sure what the exact time frame of the phase-out was, but it must've been along those lines. Still, a fuly functional System/3 ISA emulator on x86 is a shockingly bold advance in the state of computer science, that business could possibly have been moderately profitable (but they probably sunk millions into a bunch of phds for a few years and never saw a dime of direct revenue from it) if anyone had the vision to start a subsidary to sell it.

    My question is why go to C? A company going out of business never stopped anyone using its compilers. The frankenstein they came up with is considerably more expensive to create and maintain than porting it to an x86 COBOL compiler. (Maybe someone said "C is faster"?)

    This reminds me of those old futuristic movies where they had flat screens the size of a wall, and they ran a character based terminal client. GUIs would have given folks a heart attack in the 60s and 70s!

  • (cs) in reply to my name is missing
    Anonymous:

    On the other hand Sabre spent 7 years trying to rewrite the core system in a relational database and the last I heard (which was a few years ago) still hadn't been able to get it to work fast enough.

    Are all seven years part of the same gigantic, horribly mismanaged project?

  • Jim Bolla (unregistered) in reply to zip

    Actually a better strategy, IMO, is to upgrade while there are still developers who can effectively read the code of the original system whle also being able to effectively redevelop in the most modern development environment. If you still have a COBOL system, you need to upgrade to a modern environment soon while there are programmers that still know COBOL and also not something modern like .NET or Java. Once you miss that time window, you as might as well throw the original code away.

  • operagost (unregistered) in reply to J. Thurman
    Anonymous:

    I have a sneaking suspicion that this has been significantly anonymized, and that the industry was not car dealerships, but home mortgates.  This sounds remarkably like a system I worked with a few years ago when I was the lone IT guy at a mortgage company in the Phoenix area.

    You would start this application, and a window would come up with an ugly window-ized console on it, so it looked like a console app, but to make a choice, you could either type the letter "C" for "Closing," or use your mouse to click on the letter C in the word "Closing."  Ugly, pointless, but it WAS a windows app.

    That's IBM Client Access/400.  You're still running a 3270 terminal emulator to a real AS/400 (or an iSeries now, perhaps), but the "gui" elements are added to it.  This WTF is different because the old IBM iron is gone.

  • operagost (unregistered) in reply to Jonathan Thompson
    Anonymous:

    Well, so perhaps I need to extend the definition of "WW2 era" all the way to 1952 when it was first flown (not active service, but first flown), and the best information I have without digging too deeply seems to indicate the design was started in 1948.

    Do you have a pathological aversion to being corrected?  You were wrong-- 1952 is not WWII and neither is 1948.  Besides, if you use that rationale the F-117 is a 1970s-era craft and the F-22 is a 1980s era craft.  Let it go.

  • whiskey (unregistered) in reply to Tim

    I work for Reynolds and Reynolds (now owned by UCS as of Monday). I know exactly what you mean. We're using an old system for the underlying architecture. Over the last several years, we tried to migrate to a Windows 2000 + Terminal Services solution and ended up writing off upwards of $97 million and going back to the old system. I'm sure there are a lot more WTFs that could come from my company.

  • (cs)

    I actually saw a similar situation at a former client around 2002. In a matter of weeks, they ported an entire financial leasing back end from COBOL / IBM Mainframe to Windows 2000 using a converter that picks up the COBOL code and generates Delphi forms and code (also unreadable) and it worked! I forgot the name of the product they used for the conversion, but in a way it was pretty impressive. As far as I know, their developers are still programming in COBOL, but it runs completely on Windows 2000.

    I also remember that, when the product became available on Windows, users started to demand features like drop down lists and stuff and the developers needed to come up with weird tricks in their source code to make that work. I was glad to be part of the web front office development team, haha.

  • Anon-E-Mous (unregistered) in reply to Jim Bolla

     If you still have a COBOL system, you need to upgrade to a modern environment soon while there are programmers that still know COBOL and also not something modern like .NET or Java. Once you miss that time window, you as might as well throw the original code away.

     Well, you know, many (most?) banking transaction systems are running COBOL today. While they may change these at some time in the future, most are not planning to do so anytime soon. So how do they find programmers? They train them. Teaching a good programmer a new language is NOT a hurdle. If that was the case, all new languages would be doomed as well. The only hurdle is making sure they pay enough to attract decent programmers (and some banks do this better than others). COBOL is still supported and used in several industries (just not the general software industry).

    (Language experience is nice and all, but back in the day before there were a significant number of students learning these things in schools, companies actually trained people (shocking, I know!) to do things. Some companies, like banks, still do this).

  • Gabe (unregistered)

    A friend of mine had to take COBOL in college but couldn't stand the thought of actually having to code in it. So what did he do? He wrote a C compiler that generated COBOL code! Yes, this was the reverse of the COBOL-to-C compiler.

  • Old Hand (unregistered) in reply to Anon

    You're right! A few years ago I was the Chief Technical Architect on a big internet bank -we built a fancy new multi-product system, part of which was a current account for which we used our parent banks current account system. When they wrote it (in IBM Assembler) IBM hadn't finished their version of CICS, so the bank wrote their own - which they were (and still are) running...

    Now the funny thing was that when we had 70,000 accounts in our swizzy J2EE (and stuff) app, our batch window was 13 hours. The main bank's 18 million accounts were processed in a batch window of 30 minutes...

    Too young to shave programmers saying 'you must rewrite your app in my spanking new language' (perl or some other shite) and you listening to them - now that is a WTF!

  • cgibbard (unregistered) in reply to Satanicpuppy

    So, you rewrite code from a programming language of the 1960's... in a programming language of the 1970's. :)

  • RPG (unregistered)

    A few years ago I worked for a big Company that runs S/36 RPG-software on a RS/6000 using emulation software RS/36. I worked almost perfect.

    Even the operating system SSP was ported without recompiling.

     

  • (cs) in reply to Devi

    They trained their own COBOL programmers... had a whole FLOOR of them.

  • (cs) in reply to Josh

    I'm not saying yes... and I'm not saying no.

  • (cs) in reply to Josh

    Anonymous:
    Holy crap, I bet you're talking about UCS! I'm the sysadmin/netadmin at a dealership that was locked into a 15 year contract with those losers. Man, oh man, I cannot put into words how bad their software was at times. Seriously boneheaded decisions must have been made with an unheard-of frequency at that place.

     I'm not saying yes... and I'm not saying no.
     

  • UpsetOfWantage (unregistered)

    For those who think they may have made the right decision to not change: an engineer should be slightly smarter than a frog in a pan of water being brought slowly to the boil.

  • Bernhard Hofmann (unregistered)

    I guess the company will only be forced to change when they’re no longer able to employ COBOL programmers, or when they're eaten by competition using far more dynamic and reliable development environments that can more quickly adapt to changes in their customers business.

    I have too often fallen foul of these types of projects. You convince yourself that the technical challenge is worth it, and you need the money and the job, so you do the best you can to make that "action queue" or "25x80 to WinForm converter", and when you do, you're actually proud of the elegant design and robust construction.

    Your subconscious (or maybe even your conscious) tells you to ignore the bigger picture. You made this fabulous suspension mechanism, and you blinker yourself to the fact that it contributes to the manufacturing of a vegetable cart for the next F1 championship.

  • Martijn (unregistered) in reply to Another Kevin

    Rewriting code may seem like a valid option, but it can (and will) also introduce new bugs that may plague sales of the product.

    Despite the relative "beauty" of converting this system from System/3 COBOL to Windows, there is probably no real reason as far as functionality goes, whereas converting will introduce very big risks.

    As a programmer, it's sometimes difficult to understand that users don't really care that the code is in some modern language and they care even less for the fact that it uses a problematic event model. Performance is only an issue when lag is percieved. Whether an application responds in half a second or in a tenth of a microsecond really isn't important to users. And since the main business of a software company is to get money, you can't really blame them for chosing the cheapest solution. Afterall; it worked.

    p.s. If System/3 is anything like z/OS machines, I can promise you the entire event model problems can be blamed on the programmers of the application or terminal emulator. On z/OS, user interaction is transferred a screen-at-a-time (somewhat optimized). z/OS terminal applications are triggered by the user and do not actively poll to check if input is given. It's probably a matter of badly written terminal emulator, not COBOL or System/3.

  • Chris (unregistered)

    Well to be fair it's a lot more fun to write a COBOL to C translator and development environment than it is to write a car dealership system and I suppose programmers tend to produce far more and better code when they're working on something they think is kind of cool.

  • U-wing (unregistered) in reply to Chris

    Anonymous:
    Well to be fair it's a lot more fun to write a COBOL to C translator and development environment than it is to write a car dealership system and I suppose programmers tend to produce far more and better code when they're working on something they think is kind of cool.

     You hit the nail...but wait...they all look like nails to my hammer!

    I confess: been there, done that. In banking business (and governments especially) you do not simply go and rewrite hundreds of work years mass of critical software. Even if you think you could do it overnight with your Visual Whatever. And even when your laptop could run circles (and it actually does) compared to some heavy iron.

    I have yet to see large apps rewritten with modern tools modern style that run faster than their predecessors. But I have seen millions and millions wasted in state-of-the-art rewrites, ending up with truck loads of hardware running enormous pile of Java or something else that was the way to go. So the other end of this line is "no need to change it" and the other is "you have to change it everytime something new comes out". Fortunately, it's possible to see shades of gray, instead of only black and white.

    The point: this kind of wtf is not really a software problem at all. You run till you run out of hardware to run. Then you port.

  • (cs) in reply to Jon W
    Anonymous:

    What I find that vendors do, is keep the old product on life support for a long time, while they sell a newly developed product, using the new technologies. And, usually, very expensive conversion services to let the customer transition from the old to the new.

    Been there, doing that.  I support (several versions of) a product on an out-of-date version of an ancient language (OK, not quite back to Cobol).  We also sell a more modern product.  Then there's the upgrade process, consisting of several programs and scripts to convert the data.  We work on multiple platforms & multiple RDBMSs.  I leave it to your imagination how messy it is to maintain.

    Even the 'modern' product is about to be rewritten.  Life is getting interesting. 

  • Anon (unregistered) in reply to Another Kevin

    Anonymous:
    President Johnson misspoke, whereupon the aircraft's designator was changed.

    Nope.

  • (cs) in reply to vid

    Anonymous:
    > One of David's first challenges was COBOL's event model, or, more accurately, its lack of one. In standard Windows programming, when the user clicks on a button or does just about anything else, Windows raises an event to tell the application what happened. In COBOL programming, the application periodically asks if the user did an action. They were able to work around this by creating an "action queue" that allowed COBOL to see what happened and respond accordingly. This is not true. Windows creates message queue for all windows, and application periodically asks if there is some message for some window in queue. Typical way is to send this message to handler of window then.

     

    I don't think that's quite right, unless you're talking about Windows 3.x.  Since 95, applications don't poll the message queue in Windows; instead, the message queue signals the application. 

  • anonymous (unregistered) in reply to kuroshin
    kuroshin:
    Anonymous:

    Devi:
    I can just imagine in 20 years time that the last of their Cobol programmer's will die and then they'll discover that they can't find anyone who can program in Cobol to replace them

    My country (Spain) is creating new COBOL programmers. So the world will hire that poor bastards.

    We in India too seem to have the same view. Most univs here teach COBOL. I dont know how well they teach it; last time I heard, they ran out of COBOL lecturers with a positive IQ.

    But the IT services sector doesn't seem to complain. Some of the big companies that you hear about, get quite some money maintaining and plumbing these aging monsters.

    To be fair, most Universitys here seems to work with Java, Turbo Pascal, C and Visual Studio. Maybe I am somewhat wrong.

     

  • huh? (unregistered) in reply to huh

     I don't think that's quite right, unless you're talking about Windows 3.x.  Since 95, applications don't poll the message queue in Windows; instead, the message queue signals the application.

    Let's have a look at how applications DO poll the message queue:

    while(GetMessage(&Msg, NULL, 0, 0) > 0)
    {
        TranslateMessage(&Msg);
        DispatchMessage(&Msg);
    }

     
    which is Win32 code, and runs on every 32bit Windows that implements Win32. I guess that includes Vista.

    However it is not polling in the traditional sense because GetMessage() is a blocking function (it does not return until you get a message in the loop).

  • (cs)
    jdieter:

    WTF!!!

    A company that dosen't want to rewrite all their code every 2 years?  They really think you can write a program that will "still work next year"???? Impossible. Does anyone have a piece of code still running that hasn't been recompiled in years?

     

    Sarcasm meter needle is only flickering...  Assuming you're actually serious, I've written stuff that has run continously for years, much less been recompiled. By that, I mean the same process is executing, not just the customers are still happy with it.  For some uses, that's important.  Reservation systems, banks, stock exchanges, credit card processors and so on, don't want to upgrade to the Linux kernel of the week, or the language of the year.  They want to have a box over in the back that *just runs.*  Old hardware like Series/1 or System/88 did that; it boots up, and runs your apps until you shut it down on purpose.  It wasn't uncommon for either of those to have uptimes well over five years.

     And screen scraping 3270 is conceptually the same as web services, just not as enterprisey.  Screen scraping DOS apps running in a Windows DOS box, OTOH, is disgusting.
     

  • (cs)

    I can't wait to read the war stories in 10-15 years from the current generation of code monkey's on having to support legacy Java/C# mission critical apps...

  • Mike5 (unregistered)

    I read this a couple of times, but I still don't understand why if the manufacturer that is developing your compiler goes out of business your compiler stops working?

     captcha: wtf

    Cheers, Mike5 

  • anonymous (unregistered) in reply to Mike5

    Anonymous:
    I read this a couple of times, but I still don't understand why if the manufacturer that is developing your compiler goes out of business your compiler stops working?

    Maybe  the compiler makers company is somewhat integrated into the need to add/remove new components/librarys.

    Its COBOL!,  you know, the simple concept of a temporary table is doom-apocaliptical for him.  Well the simple concept of a = a + 1 is also something of giganteous effects and revolution ripples. COBOL is hard as assembler, practical for writting code as natural lenguaje (so, near zero).

    Anyway maybe is a "Alex mistake"/"anomization artifact", or something. 

     

  • (cs) in reply to operagost

     

    Anonymous:
    Anonymous:

    Well, so perhaps I need to extend the definition of "WW2 era" all the way to 1952 when it was first flown (not active service, but first flown), and the best information I have without digging too deeply seems to indicate the design was started in 1948.

    Do you have a pathological aversion to being corrected?  You were wrong-- 1952 is not WWII and neither is 1948.  Besides, if you use that rationale the F-117 is a 1970s-era craft and the F-22 is a 1980s era craft.  Let it go.

     

    In support of the original poster, I would consider 1948 "WW2-era". ('52 isn't.) If "WW2-era" strictly coincided with "WW2", what would be the purpose in using "era"?

  • (cs) in reply to huh?
    Anonymous:

     I don't think that's quite right, unless you're talking about Windows 3.x.  Since 95, applications don't poll the message queue in Windows; instead, the message queue signals the application.

    Let's have a look at how applications DO poll the message queue:

    while(GetMessage(&Msg, NULL, 0, 0) > 0)
    {
        TranslateMessage(&Msg);
        DispatchMessage(&Msg);
    }


    which is Win32 code, and runs on every 32bit Windows that implements Win32. I guess that includes Vista.

    However it is not polling in the traditional sense because GetMessage() is a blocking function (it does not return until you get a message in the loop).

     

    Like you say, that is not polling.

    Furthermore, GetMessage does not retrieve messages from the "system" message queue. 

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/messagesandmessagequeues/aboutmessagesandmessagequeues.asp

  • (cs) in reply to huh
    huh:
    Anonymous:
     I don't think that's quite right, unless you're talking about Windows 3.x.  Since 95, applications don't poll the message queue in Windows; instead, the message queue signals the application.

    Let's have a look at how applications DO poll the message queue:

    while(GetMessage(&Msg, NULL, 0, 0) > 0)
    {
        TranslateMessage(&Msg);
        DispatchMessage(&Msg);
    }

    which is Win32 code, and runs on every 32bit Windows that implements Win32. I guess that includes Vista.


    It would also have run under Windows 3.1

    However it is not polling in the traditional sense because GetMessage() is a blocking function (it does not return until you get a message in the loop).

    Like you say, that is not polling.


    It's certainly not the message queue signalling, though. You're going out looking to see if a new message is there. This is much closer to polling than any form of signalling I've used. The message queue is entirely passive - the active code is (a) the system code that delivers the message to your queue in the first place, and (b) your code that picks that message up.

    True - if the message hasn't been placed in your message queue, you don't get to see it.
  • rootnode (unregistered) in reply to Pensacola Tiger
    Anonymous:

    True, it is only a matter of time before the final part of this project dies -- the COBOL Programmers.  They will have to eventually change or the WTF will simply destroy what reputation the company has left.

    What?  You never heard of hiring a programmer and teaching him/her COBOL?  It may not be 'pretty', or object oriented, but COBOL is probably easier to learn than Java.  Most any CS graduate could learn it in a very short time.  Gawd, even Paula could be taught COBOL!  Well... maybe.

    I wasn't going to reply to this but that takes the cake!

    Most CS graduates can learn ANY language in a very short time. If they graduated with good marks, the whole point of CS is that you can code be trained to work in any language, for any environment in a fairly short period of time.

    A more significant amount of time might pass, however, before any of the programs produced by these newbies have any sort of commercially feasible application in the language of their choice. And thats where it is. Working under an architect or a software engineer is fine- "do this, patch that, import this". Working for the client where the request is "sort it out. Now." Thats a different kettle of fish and it makes no difference weather you working with Java, COBOL, C, C++, FORTRAN, Scheme, Lisp, Python, smalltalk, Delphi or whatever.

     "A bad craftsman always blames his tools" as the proverb goes.
     

     

  • (cs) in reply to rootnode
    Anonymous:

    Most CS graduates can learn ANY language in a very short time. If they graduated with good marks, the whole point of CS is that you can code be trained to work in any language, for any environment in a fairly short period of time.

    Based on my interview experience, I would have to conclude that most CS graduates can't even learn one language :-(  And yet I'm one of those people who insists that a professional programmer must have a CS degree. Go figure.

    Anyway, the problem remains that COBOL is not a "cool" technology and is not going to attract outstanding young programmers. It's going to attract the mediocre ones who didn't get past the "computing = number crunching" barrier.

  • suomynona (unregistered)

    > A company that dosen't want to rewrite all their code every 2 years?  They really think you can write a program that will

    > "still work next year"???? Impossible. Does anyone have a piece of code still running that hasn't been recompiled in years?

    Yes, there are companies around that have code running that hasn't been recompiled in years.  Granted, most of these are for embedded applications, but they do exist.  My company has customers still buying hardware from us and running software that is 12 years old.  We stopped making recompiling this code 7 years ago.  Granted, we have come up with designed advanced hardware and brand new libraries to accompany it, but our old hardware and old software hasn't changed in years and our customers are buying them -- and our customers haven't changed the code either because their customers are still buying their older machines too.  Even though the revenue from these old customers goes down each year, and even though my company's revenue continues to grow each year due to new business with our new hardware and libraries, the old stuff that we haven't changed in over 7 years continues to bring in over 5% of our revenue.

     

    Here's sone examples of embedded applications where code cannot be recompiled, but must run for years without being recompiled -- software for automobiles, DVD players, watches (yes, many of them run software), scientific calculators.  And there are many, many others.

     

  • joe (unregistered)

    I'm at a company doing a similar thing (but not COBOL).  And I can tell you, cost and complexity have nothing to do with it.  It's all politics.

    Management sayeth, We are not a software development company.  Therefore, anything we use has to be off-the-shelf ... but we're allowed to customize it.  Of course, after a couple years of this, our customizations almost completely hide the original app, are bigger and more sophisticated than it, and consist largely of working around bugs in it.  Oh, and the off-the-shelf app has been discontinued.  It would be easier to start from scratch, or even remove the original app and rewrite the parts of it we need from scratch, but that's verboten.

  • OldFart (unregistered)

    OK, I'm old. Really old, at least in terms of "IT". I am retired now, but I got started in the IT industry, then called EDP (Electronic Data Processing) in the 1960s. Yes, I worked on punched cards; I've punched my own on a real IBM 029 card punch, even an occasional 026 card punch, ancient even then. Hell, I recall writing "actuals" for 7010 machines. To write actuals, you used a big coding sheet, 17" wide. You coded assembly language in the space provided on the right hand side of the sheet, then hand assembled your own coding into actual machine language op codes on the left side. Then, you used the 029 to multi-punch your hand assembled code, the hexadecimal code, onto punched cards. The card deck was "booted" directly from the card reader using a "one card loader". I could regale you with war stories of all kinds, but I'll limit my story here to one similar to the WTF story here.

    Once upon a time in the early 1970s, I worked for "A Big Bank" as a systems programmer. My assignment was to install a 7010 emulator onto OS/MVT (a predecessor to what later became OS/MVS). Why?

    It seems that there was this application originally developed for tabulating machines, the predecessors to digital computers. A particular part of the original application was intended to be run on an IBM 407 accounting machine. When the physical 407 had to be taken out of service because it was no longer supported by IBM, the bank ran the application, in emulation on an IBM 650 Computer System. Later, when the 650 had been retired, the application was run on an IBM 1401 computer emulating the 650 emulating the 407, but slowly. When the bank got an IBM 7010 computer, a heavy weight variant of the IBM 1410 computer, itself an extension of the 1401 computer system, the application was ported to the 7010 emulating the 650 emulating the 407. When the 7010 was no longer supported, that's where I came in. My job was to get the 7010 emulator running on an IBM 360/50.

     I got it running. The original 407 accounting machine application was running daily on a 360/50 emulating a 7010 emulating a 650 emulating a 407. That was about 1973, I think. When I left the bank in 1975, the 407 application was still humming along. Never mind that there was no 407 anywhere within the enterprise, nor anyone who could remember how to do the plug boards to "program" it. Nobody really remembered the 650 and I was one of the few to remember a real 7010. Somehow, I imagine that system still runs today, emulated by God knows what.

    To say the least, the industry has come a long way. ... Well, sonny, back in the early days, we walked to school barefoot in the snow, up hill both ways, against the wind! ... Modern tools, sheer speed of computers, and the whole concept of computer science has grown to maturity, for some value of maturity, since I started in the business, did my thing and retired. You should have been there. You'd have loved it.

    OldFart!
     

Leave a comment on “No Need to Change It! ”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article