• (cs) in reply to Dave
    Anonymous:

    After reading this, I tried to reply by clicking the "Report Abuse" link. Isn't that the only reasonable thing to do?

     :-)

     

     

    Sidenote - how come only SOME posts have "report abuse" links? Are some users pre-screened and certified Abuse-Free?

     

  • I do computers not HVAC (unregistered) in reply to Mike5

    The compiler stopped working because it was from the bad old days when you had to pay for yearly maintence in order to get a license key to keep it working.

     

    As for the whole WTF; at least they hired proper computer people to build their translators rather than hiring consultants.

  • (cs) in reply to OldFart
    Anonymous:


    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.

    At some point, wouldn't it have been easier to write a simulator for one of the older boxes that ran on one of the newer ones to cut out a level?  I suspect, without being familiar with those specific models, that the older ones were simpler, so writing a 407 emulator to run bare on the 360 would be easier than writing an emulator for the 7010, and would cut out the 1401 and 650 layers.  Or were these off-the-shelf emulation packages?  I recall IBM used to do that a lot. 

    Anonymous:

    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!

    Dang!  Computin' was fun back then!  :-)
     

  • anonymous (unregistered) in reply to Alexis de Torquemada
    Alexis de Torquemada:
    Anonymous:

    GIVE ME A BREAK!  I hate COBOL as much as ANYONE!  REALLY, I DO!  Oddly, I once had to do something SIMILAR!  My employer had a product written in a fortran like language, and a customer INSISTED that it be ported to COBOL on WANG!!!!!!!  WANG went BANKRUPT!  NO computer, NO compiler, etc........!   SO, we KEPT it in COBOL!  We KEPT it running like Wang VS!  The customer wanted that, but they could NOT accept it running on an unsupported computer.  I simply ported it to ANOTHER COBOL!  One that is STILL made EVEN TODAY, and runs on perhaps every platform out there INCLUDING M/S and X windows!  So the REAL WTF is that david didn't do the same!

    DO you hate CAPS LOCK as much as I DO? My hate of CAPS LOCK goes so far that I REMOVED the caps lock KEY from many a KEYBOARD that sported it. 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?!!!!!!!!!

    The only thing that spared my PowerBook keyboard the SAME FATE was that Mac OS X actually has a NICE OPTION in the SYSTEM SETTINGS where you can easily TURN OFF caps lock if you DO NOT NEED IT!!!!! On the Windows NOTEBOOK I use at work I installed a REGISTRY HACK which turned the shift lock key into CONTROL, just like those old SUN TERMINALS we HAD AT university when I was a STUDENT. It even required a REBOOT but now it works fine I am so RELIEVED that I no longer screw up by accidentally hitting SHIFT LOCK all the time.

     

    Umm, no its not. Caps lock on windows works like it is supposed to. Numbers still work correctly with caps lock on.

    I've never seen some one so stupid that they can't avoid hitting caps lock by accident all the time, but I guess now I have. 

     

  • (cs) in reply to my name is missing
    Anonymous:
    The SABRE reservation system is just such a beast. The inner part stil thinks it the late 60's, several layers of hardware and convertors later you get the new modern interfaces. The inner code is written in MVS assembler, with physical raw pointers to disk sectors as the 'relational' function. Whenever they need new data they just borrows bits from various places and combine them together to form new data structures; its easier than rewritting the entire database to add a few bytes. I kid you not, but it works reliably and handles 8000 transactions per second.

    It's impressive to see a system running in the TPF operating system, processing 5000-8000 transactions per second.  I used to work for American Airlines as a programmer (although not directly on the Sabre system, but on the VM systems that were used as TPF test systems).

  • My Lord! (unregistered)

    My innards have just become my outards.  Anyone have a tissue?  Captcha = paste :-)

  • Cody (unregistered) in reply to anonymous
    Anonymous:
    Alexis de Torquemada:
    Anonymous:

    GIVE ME A BREAK!  I hate COBOL as much as ANYONE!  REALLY, I DO!  Oddly, I once had to do something SIMILAR!  My employer had a product written in a fortran like language, and a customer INSISTED that it be ported to COBOL on WANG!!!!!!!  WANG went BANKRUPT!  NO computer, NO compiler, etc........!   SO, we KEPT it in COBOL!  We KEPT it running like Wang VS!  The customer wanted that, but they could NOT accept it running on an unsupported computer.  I simply ported it to ANOTHER COBOL!  One that is STILL made EVEN TODAY, and runs on perhaps every platform out there INCLUDING M/S and X windows!  So the REAL WTF is that david didn't do the same!

    DO you hate CAPS LOCK as much as I DO? My hate of CAPS LOCK goes so far that I REMOVED the caps lock KEY from many a KEYBOARD that sported it. 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?!!!!!!!!!

    The only thing that spared my PowerBook keyboard the SAME FATE was that Mac OS X actually has a NICE OPTION in the SYSTEM SETTINGS where you can easily TURN OFF caps lock if you DO NOT NEED IT!!!!! On the Windows NOTEBOOK I use at work I installed a REGISTRY HACK which turned the shift lock key into CONTROL, just like those old SUN TERMINALS we HAD AT university when I was a STUDENT. It even required a REBOOT but now it works fine I am so RELIEVED that I no longer screw up by accidentally hitting SHIFT LOCK all the time.

     

    Umm, no its not. Caps lock on windows works like it is supposed to. Numbers still work correctly with caps lock on.

    I've never seen some one so stupid that they can't avoid hitting caps lock by accident all the time, but I guess now I have. 

     

    Someone seems to have missed a joke. 

  • Nathan (unregistered) in reply to Josh

    UCS was the first name I thought of too! Back in college I used to work for them as a bench tech. I still feel dirty about what we did to people.

  • doc0tis (unregistered) in reply to Lummox

    Didn't anyone do a proper ROI?

  • HatTrick1914 (unregistered) in reply to anon
    Anonymous:

    "That is, until the manufacturer of their COBOL compiler went out of business."

    So why didn't they just continue using the compiler they had?
    There surely was no need to change it... ?

    Yeah that part kinda puzzled me too.

  • jminkler (unregistered) in reply to Anon
    Anonymous:

    Anonymous:
    In all honesty, I'm amazed this works.  Let's see what all of these 'Brillant' people do when Vista comes out . . .
    Yeah, WOOOOO! You showed them! Boy, just wait until Vista comes out and they have no choice but to upgrade.  Man everything's going to break, and those losers won't know what hit them.

     

     

     

    Or maybe they won't care about Vista, and they'll just not install it.

     Until MS no longer supports XP ...

  • Rich (unregistered) in reply to jminkler

    Seems like it was a fairly reasonable transition to me. They make their money on their core app which works just fine so keep that part nice and protected and ensure it has a decent environment to work in.

     

    That said, when it had to be Windowsified, it would probably have made sense to parallel develop a fork which would allow the COBOL to run on Windows. Perhaps making it cross-platform by creating an API that wraps closely around MFC

     

    Rich 

  • Nobody (unregistered)

    Wait a sec... "car dealership" is really "computer software manufacturer", "System/3" is "8086" and "COBOL" is "DOS". It's the most backward of the backward-compatible companies...

    Microsoft?

  • David Shideler (unregistered) in reply to Lummox
    Anonymous:

    I was quite surprised to see people siding with this friggin kludge monster.  I didn't know there were people on here that were advocates for such poorly thought out practices. 

     Cost efficiency?  If they're bringing in teams of 'computer whizzes', I doubt they're going out and hiring people; they're probably talking to a consulting agency and paying consultants $100 an hour to do this.  I would infer this from the fact that it's always 'another team' of people.  What guarantee is there that if something breaks any of these people that are employed for the company will know what one of the 'other teams' did to patch this thing together?

     And also, it's ACCOUNTING SOFTWARE.  Is it seriously so unbelievably complex that any hope to rewrite it has been abandoned and that people spontaneously combust just from considering re-implementing this?  I highly doubt the end justifies the means, not to mention the fact that you're going to have a hard time maintaining this when your staff leaves. 

     In all honesty, I'm amazed this works.  Let's see what all of these 'Brillant' people do when Vista comes out . . .

    Actually, they DID hire their own computer whizzes.  I was part of the "Systems" team that was responsible for making all this software glue/duct tape that held everything else together.  They had an amazingly well-tuned recruiting department (probably still do).  One of my co-workers had gone in looking for a factory job and ended up programming for peanuts.  Add to that the fact that they give people a $1500 or so bonus if you refer somebody that gets hired for at least a few months... Not that I'd ever refer anybody to that company unless they were as desperate for work as I had been. 

  • tomliotta (unregistered) in reply to David Shideler
    Anonymous:

     And also, it's ACCOUNTING SOFTWARE.  Is it seriously so unbelievably complex that any hope to rewrite it has been abandoned and that people spontaneously combust just from considering re-implementing this?

    I suspect you've never worked for a significantly sized State government agency that has mandates for reporting accounting info up to Federal agencies. There's 'accounting software' and then there's "ACCOUNTING SOFTWARE". The Feds get sticky when a few billion bucks are involved annually. I've also worked for a couple multi-billion-dollar multi-nationals and 'accounting' is not trivial.

    Anonymous:
     

    ... Not that I'd ever refer anybody to that company unless they were as desperate for work as I had been. 

     That seems odd. Why not? I'd think the technology insights within such a place are likely far beyond average. The various wrappers almost certainly need a significant amount of maintenance themselves just so they can continue running as service packs are supplied, etc. What could be more challenging?

    Now, remaining with old COBOL is a different question. Modern COBOL is essentially unrelated. I write COBOL routines on some current IBM systems for some specific purposes and there isn't a C library function that I can't use directly. It might seem strange to some to see a memcpy() or atoi() or whatever used in a COBOL module, but COBOL hasn't stood still just because years have passed. It's too bad any COBOL developers at the subject company weren't allowed to keep up.
     

  • Intangir (unregistered)

    you left out our clever nickname for the cobol crap with windows forms project

    "cobol foundation classes" (a rip on MFC, microsoft foundation classes)

     

  • (cs) in reply to Nobody
    Anonymous:

    Wait a sec... "car dealership" is really "computer software manufacturer", "System/3" is "8086" and "COBOL" is "DOS". It's the most backward of the backward-compatible companies...

    Microsoft?

     
    MS is hardly the most backwards compatable company. By my understanding, most IBM System/370 binaries will run unmodified on their latest zSeries mainframes. The S/370 was announced half a decade before MS was even formed.

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

    "That is, until the manufacturer of their COBOL compiler went out of business."

    So why didn't they just continue using the compiler they had?
    There surely was no need to change it... ?

    Yeah that part kinda puzzled me too.



    I don't get why so many people don't get this.  Say you've got a mission critical app that goes down.  Millions of dollars per hour are being lost and/or people's lives are at stake.  You quickly find and fix the bug, and go to recompile it, and the compiler crashes (seen it happen folks).  Compiler is no longer supported so it can't be fixed.  Now you have no choice but to upgrade to a different compiler.  This kind of conversion can take weeks
    or even months for a really large application program, especially if the program is an old undocumented legacy
    POS using undocumented language "features".  Guess what? You're out of business!  I've worked for many large companies, and never seen one yet that's willing to take a risk like this.
  • Sam Thornton (unregistered)

    This is a fascinating thread. It raises the question of what to do with legacy code, especially when it is complex and fulfills critical requirements. Put another way, as technology evolves, do we want to spend the next thousand years continually reinventing the wheel, or do we want to build on the successes of the past?

    I'm not smart enough to know the best answer, but it seems to me these questions might point to a possibly significant market for legacy integration.

  • Onion (unregistered)
    Alex Papadimoulis:

    But that didn't matter; their system worked and there was no need to change it......

     After all, they found a formula that worked and there was no need to change it.

     

    Well, unfortunately this kind of altitude is very common in lT industry. I have personal working experience in 2 large systems.

    The core of this issue is not a technological one but more a human kind - fear of placing oneself in a new territory thereby being a junior or newbie. Most commonly is that organisations of this kind are lead by people with expired knowledge.

    You don't have to look too far. Quicken 2006 & MYOB and many well known accountant packages are still failing to comply with the Windows 2000/XP security model. Some can't even accept long file/directory names.

    While IT is supposedly one of the fastest pace industries it's amazingly that it has the largest collection of Ultra conservative risk adverse workers.

    As a result of these stubborness the consumers are ending up paying for these defects and suboptimal solutions. 

  • Michael Wojcik (unregistered) in reply to Pensacola Tiger
    Anonymous:

    It may not be 'pretty', or object oriented, but COBOL is probably easier to learn than Java.

    COBOL is OO now.  Proprietary OO COBOL has been around since at least the early 1990s, and the OO features of COBOL were standardized in ISO COBOL 2000.

    Of course, most existing COBOL code is procedural, but it's certainly possible to write new COBOL with all the encapsulation, polymorphism, and inheritance you like.

    (And it's actually possible to write fairly pretty COBOL these days, too, thanks to free-format source, and the fact that few developers have to work on monocase terminals.)

    Anonymous:

    Most any CS graduate could learn it in a very short time.

    Indeed.  CS graduates who couldn't learn COBOL in a short time should return their degrees.  COBOL does have quite a few dark corners, thanks to the way it's evolved (decades of incorporating special features invented ad hoc by various implementors, plus periodic efforts to provide alternatives to the language's greatest shortcomings), but so does C, or C++, or most other languages.

     

  • Michael Wojcik (unregistered) in reply to huh
    huh:

    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.
     

    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.

    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.

     

    You'd better let MS know that their documentation is wrong, then.  From the September 2001 MSDN Library, Platform SDK, Windows API, A Generic Sample Application, Entering the Message Loop:

    The system does not send input directly to an application. Instead, it places all mouse and keyboard input from the user into a message queue, along with messages posted by the system and other applications. The application must read the message queue, retrieve the messages, and dispatch them so that the window procedure can process them.

    The Generic application uses the following message loop:

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

    The message dequeue-and-dispatch loop doesn't have to be explicitly implemented in application code, of course; it can be part of some third-party framework or library, which can dispatch to a set of registered callbacks.  If that's in a separate thread, you have an asynchronous event model in the application, but it's still built on top of a synchronous dequeue-and-dispatch model provided by the environment.

    And DispatchMessage just calls the window procedure assigned to the window that's the target of the message, which in the MS example is just a switch statement on the message type.  No "event model" magic happening there.

     

    All that works just as well with COBOL as it does with any other procedural language.  It was designed for C, and attentive readers of the ISO C standard will note that C doesn't have an "event model" any more than COBOL does.

    The real WTF is that this entire "event model" paragraph somehow made it into this story.  It's complete nonsense.

     

  • David Shideler (unregistered) in reply to Michael Wojcik
    Anonymous:

    The real WTF is that this entire "event model" paragraph somehow made it into this story.  It's complete nonsense.

    You don't think it's a WTF that we had to re-invent the event model for COBOL?  And the real problem is that our old-school COBOL had no callback mechanic at all.  So, you just have to pray that the program is executing itself quickly enough that it'll actually grab your events in a timely fashion, otherwise who knows what kind of behavior you could get.  Of course, I suppose with a regular windows program, you'd just throw up a wait cursor in those cases, and I'm sure we could (and probably did) give those programs a way to do the same...  But with as many legacy COBOL apps as they were running, what do you figure the odds are they're going to go through every program and insert code to throw up wait cursors whenever they have a section of code where they're processing and don't ask for user input for a while?

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

    "That is, until the manufacturer of their COBOL compiler went out of business."

    So why didn't they just continue using the compiler they had?
    There surely was no need to change it... ?

    Yeah that part kinda puzzled me too.



    I don't get why so many people don't get this.  Say you've got a mission critical app that goes down.  Millions of dollars per hour are being lost and/or people's lives are at stake.  You quickly find and fix the bug, and go to recompile it, and the compiler crashes (seen it happen folks).  Compiler is no longer supported so it can't be fixed.  Now you have no choice but to upgrade to a different compiler.  This kind of conversion can take weeks
    or even months for a really large application program, especially if the program is an old undocumented legacy
    POS using undocumented language "features".  Guess what? You're out of business!  I've worked for many large companies, and never seen one yet that's willing to take a risk like this.

    You're an idiot, You have never seen this happen. What, a compiler wears out after a time? I have been programming since 1978 and have NEVER seen a compiler just stop working..... bugs maybe, but that has never stopped us from using it with some creative work-arounds and I really do work with mission critical and safty related software so give me a break and learn something usful.

  • (cs) in reply to David Shideler
    Anonymous:
    Anonymous:

    The real WTF is that this entire "event model" paragraph somehow made it into this story.  It's complete nonsense.

    You don't think it's a WTF that we had to re-invent the event model for COBOL?  And the real problem is that our old-school COBOL had no callback mechanic at all.  So, you just have to pray that the program is executing itself quickly enough that it'll actually grab your events in a timely fashion, otherwise who knows what kind of behavior you could get.  Of course, I suppose with a regular windows program, you'd just throw up a wait cursor in those cases, and I'm sure we could (and probably did) give those programs a way to do the same...  But with as many legacy COBOL apps as they were running, what do you figure the odds are they're going to go through every program and insert code to throw up wait cursors whenever they have a section of code where they're processing and don't ask for user input for a while?

     

    Actually I believe if your program goes long enough without returning from its callbacks (or something like that) Windows will put up the hourglass for you. It's not as nice as if the app does it because Windows can't predict what you're going to do, but it's at least better than nothing.

  • David Shideler (unregistered) in reply to EvanED
    EvanED:

    Actually I believe if your program goes long enough without returning from its callbacks (or something like that) Windows will put up the hourglass for you. It's not as nice as if the app does it because Windows can't predict what you're going to do, but it's at least better than nothing.

     

    Well, first off, I don't think that's true... but more importantly, our application was handling events as they came in and queuing them up to hand off when the application started accepting input again.  I think we limited the number of events you could queue up, but we didn't want the whole program to freeze up every time we had an event.  And it's not like you'd want to put up a wait cursor every time an event happened, either.  That would get really annoying really fast.

  • Bob Frankston (unregistered)

    The actually is a COBOL for Windows, .Net even -- http://www.netcobol.com/products/windows/netcobol.html. Perhaps after hyperventilating so long they'll have to invest in a C=>COBOL reverse translater in order not to break their chain of kludges.

    BTW, 1200bps is very fast ... 110bps (AKA 10CPS), now that's slowish but faster than ...

  • Anonymous (the OP) (unregistered) in reply to poochner
    ...so writing a 407 emulator to run bare on the 360 would be easier than writing an emulator for the 7010, and would cut out the 1401 and 650 layers.  Or were these off-the-shelf emulation packages?

    I cannot vouch for the emulation/simulation of the original 407 application prior to the 7010 emulator on the S360/50. The 7010 emulator on the S360 was indeed an IBM package (Program Product). 

    A discussion on 1401/7010 emulation on S360.

    Here is a reference to the S370/158, an architectural successor to the S360. In the document is this reference to "integrated emulators".

    Integrated emulators supported the concurrent execution of System/370 programs with 7070/7074, 1401/1440/1460, and 1410/7010 programs in a multiprogramming environment.

     

     

  • been there...I am there... (unregistered) in reply to whiskey

    Anonymous:
    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.

    A little advice for Anonymous at ReyRey, as of Monday, be carefull what you post on the web.

    This story was posted two days ago, I am surprised that lawyers representing ReyRey's new owner haven't issued cease and desist orders yet!

    This story wasn't really annonimized very well.

  • Anon (unregistered) in reply to Anon
    Anonymous:

    There is no need to change it.  You don't have to debug code you don't write.  As long as each emulation layer is smaller than the package it's wrapping, and performance is still acceptable, they're doing the right thing.

     

    This is the approach taken in health care by some large companies. I work with a system that is terminal based, the company that sells the product made their own terminal emulator that gives a few windows "toys" (message box buttons and selector lists). When they moved to the web, they created an activex control that is the terminal emulator, and instead of just drawing lines and text will draw things as buttons and different colors. It does do a few more fancy things that are specific to their app, but it's essentially a wrapper.

  • Martini (unregistered)
    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?

     

     

    I have code that has worked for 6 years right here, still works, nothing is wrong with it yet. Rewriting everything in 2 years shows just one thing : f-in bad source design. Good code can be updated without rewriting. However the issue in this article certainly does not go for good design ;-)

     Sometimes systems are so complicated that it takes 2 years just to write them and errorcheck them, and sometimes old good clients require you to stay with what you have instead of breaking everything apart for a new solution that lasts only a few months :)




     

  • (cs) in reply to John Hensley

    I used to chuckly when I saw a store using an old Clipper app. But reading this has brought me back to reality a bit. Old Clipper Apps worked really well. Why would a store want the 6 months+ it would end up taking to switch to a new system that probably hasn't been debugged very well? Their app works perfectly well for them and doesn't cause any problems so why not an emulator?

    RL example: "Oh, you need to get this propane tank re-certified and it costs about the same to buy a new one, so you should just buy a new one."

    "Well, if it doesn't cost any more to get the old one re-certified, then I'll do that and save creating extra garbage."

  • (cs) in reply to t'ni

    (sorry for double post, don't know if that's a faux paus here)

    ps: Does anyone know of an emulator so I can run Win98SE on my hardware that only has WinXp drivers????

    This is not a joke!!???

  • (cs) in reply to been there...I am there...
    Anonymous:

    This story was posted two days ago, I am surprised that lawyers representing ReyRey's new owner haven't issued cease and desist orders yet!

     What, and admit this story is about them?
     

  • (cs) in reply to savar
    savar:

    Translating a terminal interface into a Windows interface on the fly? Once again, hurts my head.

    I've used a system that did this. It was called "Phoenix" (IIRC), and ran on a UniVerse-databased system, and it had 2 interfaces. The faster and much more fully-featured was the proper (n)curses-alike telnet version. However, for those who used the system rarely (Business sales account managers, mostly), there was a second, more windows-alike version. This version logged into the telnet session, scraping the interfaces there and generating modal dialogs from them (Because you couldn't switch focus between "windows" over the telnet interface) to accept the input.

    It was almost literally a case of "Read the input stream, looking for the ascii top-left character. If you find one, this is a new window. Read the dimensions (in characters) and convert to pixels/picas/twips to draw the new window, then send lots of tab characters to cycle through all the available fields and pick up their start-points (and if they are dropdowns, their contents)."

    It worked, but it was slower than molasses at absolute zero, and prone to causing many problems with incorrect character escaping and encoding.

  • Michael Wojcik (unregistered) in reply to David Shideler
    Anonymous:
    Anonymous:

    The real WTF is that this entire "event model" paragraph somehow made it into this story.  It's complete nonsense.

    You don't think it's a WTF that we had to re-invent the event model for COBOL? 

    COBOL doesn't have an "event model", any more than C or C++ or LISP or APL has one.  Consequently, you couldn't have had to reinvent it.

    Event models are algorithms, not language features.

     

    And the real problem is that our old-school COBOL had no callback mechanic at all.

    Implementing callbacks in any language only requires three things:

    • Conformance to the platform ABI, so that the caller can call your routines
    • Support in the language implementation for multiple routines
    • Support in the language implementation for passing the address of a routine to the caller

    The first had to be present in your COBOL implementation, or you wouldn't have been able to write COBOL Windows apps of any sort.  The second has been part of standard COBOL for as long as there's been a standard COBOL; if your COBOL lacked it, it wasn't COBOL.  The third is part of every Windows COBOL implementation I've seen, and if yours lacked it, then presumably you could have added it, since you were using this home-grown "translate to C" implementation anyway.

    Look, I have no doubt that the application was a mess, and it's event model may well have required reinvention.  But blaming some nonexistent "COBOL event model" problem is simply incorrect.  There have been numerous COBOL implementations for Windows, there still are COBOL implementations for Windows that sell very well, and COBOL programs for Windows can be written using the same techniques that Microsoft describes for other languages.  (Some - but by no means all - of those techniques require features that are extensions to standard COBOL.)  There's nothing inherent in COBOL that makes it unsuitable for writing Windows applications, and indeed there are hundreds, perhaps thousands, of COBOL Windows apps in use around the world.

    Michael Wojcik

     

  • Anton (unregistered)

    Didnt read all the posts, but, unh...just wait till Vista hits these guys...

     

    CAPTCHA: perfection

    Suitable I guess

  • Tobias (unregistered)

    Actually I used to work in a company which did quite the same thing with their software (a ERP-System). They were using  COBOL a propritory COBOL-Precompiler, a COBOL-To-Windows-Runtimesystem and last but not least a ISAM-Datamanagement. But arguments like encapsulation, test-driven-development and a database that would be a lot more flexible were not heared. Instead one went on to develop his own ISAM-To-SQL-Data-Access-Layer, his own Precompiler to implement things like generics and functions or macros. And it worked! Suprisingly, but....!  I later quit because I could not adjust myself to this kind of work after exploring the .NET-Framework and the possiblities of C# and SQL. Meanwhile I like to compare this behaviour to an electrican who refuses to use an electric HILTI instead of a hammer and a chisel.

  • Ex-UCS (unregistered) in reply to Josh

    Yes - this is exactly what UCS did.

     

    I used to work for a software company in the UK that was bought out by UCS.  We were all doing dealer management systems in Oracle and UCS wanted us to convert to COBOL.

     

    Needless to say, I left before doing any COBOL.

     

    Funny thing was, these guys were really proud of their product.  They were even developing an IDE (integrated development environment) for their COBOL development.

     

    I can also confirm that the very highest levels of management had some very strange ideas in general.  Much of the UK staff became quickly alienated and left the company within a couple of years of the takeover.   The VPs thought they were the best thing to happen to software development, ever.

     

    I still remember the look of horror on the face of one VP when we suggested that we might have to upgrade our Oracle development environment because Oracle didn't support it anymore...

     

    Oh, the stories I could tell about that place - legally I guess I better not! 

  • Ex-UCS (unregistered) in reply to Ex-UCS

    I think the people defending UCS and this practice of hopelessly clinging onto out of date technology have to remember that UCS have also bought out other DMS software suppliers recently with far more modern systems (e.g. Kalamazoo in the UK), halted development on the modern systems and promoted ol' faithful instead - hence the need for the Windows (or more accurately, Windows style) interface.

     So, they didn't even have to endure the cost and difficulty of development new systems with modern technology - they were given it on a plate with the acquisitions and still kept the old ways!

    This practice of trying to force customers to adopt the old COBOL system has forced many of the former Kalamazoo Elite customers to buy the Kerridge (major UK competitor) DMS instead.  D'oh!  I can't reveal how many or exactly who though...
     

    OTOH, UCS do this mostly because ol' faithful is still very profitable.  I guess that's one thing that does make a lot of sense.  Is it sustainable?  So far, so good..as they say.   How profitable, nobody knows because UCS is a private company that doesn't publish public accounts.


    There are signs of trouble though.  UCS have a Spanish language version of the software (what being based in Texas and all) and thought it would be a walkover entering the Spanish market in Europe.  It didn't quite work out that way...  Could be a marketing failure or maybe potential customers were turned off by proprietary hardware running with ancient software and no-back up from the majors like Oracle or Microsoft?
      I can't answer that...

  • CRM Developer... (unregistered) in reply to Tim

    Argument about "multiple dealership" and various price price points is not valid because you can get some brand new stuff from the company formely known as peoplesoft or MySAP that perfroms everything that you describe and proovides fast realtime information...that looks pretty and in 3D!

  • cinnamon colbert (unregistered)

    as a scientist and a business person, I think this compnays strategy was good - did they makes their sales nubmers ? did they have good margins ? would htey have done better switching ? these are the questions u shd be asking before being snotty and posting on wtf

  • David Shideler (unregistered) in reply to cinnamon colbert

    Anonymous:
    as a scientist and a business person, I think this compnays strategy was good - did they makes their sales nubmers ? did they have good margins ? would htey have done better switching ? these are the questions u shd be asking before being snotty and posting on wtf

    Massive spelling errors aside... I understand WHY they did what they did.  If it ain't broke, don't fix it, sure... And they had a lot of resources tied into the existing model, most notably their entire floor of COBOL programmers.  Time to re-train, or re-staff, plus development and debugging time for what is I'm sure a monolithic suite of applications...  But at the same time... At some point, isn't it just a bad idea to keep piling band-aid after band-aid on top of each other?  Don't you, at some point, have to TRY to do things a new way?  Even a slow migration plan, where you start building new applications that can interface with both old servers and new... phasing out the old COBOL apps as their functionality becomes redundant... I mean, at some point, all this old technology is just going to crash and burn... and then where will they be?  Focusing ONLY on short-term goals will get you into big trouble down the line.  Sometimes you just NEED a fresh start.

  • Peter da Silva (unregistered) in reply to zip

    "They have to rebuild it at some point, since the patch/adaptor/emulator stack can only go on for so long, and it gets worse (and more outdated) each time."

     

    You are Pham Nuwen and I claim my Deepness in the Sky. 

  • Peter da Silva (unregistered) in reply to CRM Developer...

    I've used SAP.

     It sure looks like COBOL running under Windows to me, as a user. Are you SURE you're not talking about the same company?

  • Ex-UCS (unregistered)

    This has to be the dealership software company based in Houston.

    I once heard the VP of product development / CIO state back in 1994 that the internet was just a fad and would go away in a few years... It was too had to find anything was his reasoning...

    The company purchased Ford's dealership software in the early 90's, thus "locking in" every Ford dealership onto it's proprietary system.

     It is/was a private company that started by performing parts inventory data processing for car dealerships.

    The company has some of the largest dealerships in the world. Anyone ever hear of Longo Toyota in LA?

    This company has/had it's quirks such as:

    1. Had to wear a suite every day.
    2. No smoking, ever...
    3. "clock in" using a key pad and destination code, on every door. There was an internal program where you could tell when/where someone last clocked in. (someone punch in my digits, I'm going to be late)
    4. Use a personal calling code so they could track each and every phone call.
    5. Posted Phone abusers list for those making too many personal calls.
    6. the list goes on...
  • Take That (unregistered) in reply to Lownewulf

    I worked in the web division for reynolds which was just purchased by UCS and I can tell you that most admins didn't have a whole lot of say in what systems were in place and had little or no input on the dealer management system.  The company they are talking about is UCS.  UCS couldn't make the transistion so they bought Reynolds (Match Made In Contract HELL).  UCS really got big with Ford Dealers as they had a great parts catalogue system.  Well long story short UCS is involved in a class action suit with Ford Dealers what I would say highway robbery.  Here is the short version of how it would work.... a dealer would sign a master contract covering all services i.e. terminals, software, updates, etc.  well every year the OEM's come out with new catalogues so when the dealer would call to update ....UCS now Reynolds and Reynolds would say sure Mr. Dealer just sign hear ... well the dealer didn't read the fine print and in there would be a contract ext.  So that is how most of the dealers get in a long term contract.... If I were a dealer i would be chomping at the bit waiting for Microsoft to come out with thier dealer management system..  It will be a whole hell of lot cheeper.

  • Ralph (unregistered) in reply to Anon

    You gotta be kidding me.

    You call the staying in the old system instead of moving on to the new one where new would be in result a)faster b)less expensive (freee IDEs & tutorials are all around the net) c)more popular d)looking better e)smaller (you ain't gonna tell me COBOL code will be smaller than e.g C code, right) doing the right thing??

    You just need to be open to changes when staying in status quo is clearly not beneficial. The guys from article were not. And they suffer.

  • Kuba (unregistered) in reply to l1fel1ne

    Especially if you can just buy the darn thing and it's so darn cheap. Kobol from TheKompany. No, I don't work for them. Maybe the anonymization really hides the fact that they do talk about Kobol? It just looks too similar to be a coincidence!!

  • hobbit (unregistered)

    Was that company's name "AutoSoft?"

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

Log In or post as a guest

Replying to comment #98328:

« Return to Article