- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
The think the amazing thing is that this actually worked.
It'd seem to me that at some point they should try and convince management that it's LESS work to rewrite the thing from scratch than to continue with this magical emulation support.
Admin
Psssh. I wouldn't have taken 6 figures to work for a company like that. I've got a ton of legacy (cobol) accounting code where I work now, and whenever someone asks me to update a program in cobol, I rewrite it in C.
It's the only way to work with systems like that. You have to make a clean break, because it just gets harder and harder over time, as the people who originally worked on the migrations off your crappy legacy system, retire and die, and when they're gone, that's it. Can't look that crap up on the internet...Any records there may have been are sitting on some moldering magnetic tape somewhere.
Admin
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.
Admin
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.
Brilliant!!! Can you come work for my company? You're AWESOME!
Admin
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]
Admin
Wow... Usually when something like this happens, the product really doesn't work, but works "good enough."
I can't tell you how many times I've heard "It'll take too much time to scrap it, just put a cost effective band-aid on it."
ugh.
:-j
Admin
Remember that it might anonymized.
But jeeze, how can people think this way? More importantly, who is buying this thing and keeping it going? I assume they're providing work for, what, a dozen bitter COBOL programmer?
Admin
And quite right too.
It's too often that Managers give in to their urge to use the newest bestest fastest whatever, which means hacking apart an established well tested system. These people inspired creativity in the programming teams...
CAPTCHA: initech (hah!)
Admin
Holy crap, that is awesome. But how does this company remain profitable? (or is that an unreasonable assumption?) It sounds like they hit it big by being the first company to make "car dealership software" (probably anonymized) -- shouldn't they be losing all their inital customers to their competitors who have, I dunno, adopted a single new technology in the last 30 years?
Admin
Did they spin off the System/3, Cobol-to-C translator, and Windows GUI tools and sell them to other companies in similar situations? That would have been a nice bonus.
Admin
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. Maybe, they should try upgrading their codebase/product while they still have customers?
Admin
Wrong math. merely comparing the emulation layer to the package its wrapping way oversimplifies it. You need to account for "size" (in what sense? who knows what you really mean) of enhancements to the original and adjust for potentional enhancements that could be gained by changing platforms.
Remind me not to let you run any company I work for.
** Martin
Admin
A classic example of do nothing until it breaks. When it breaks what do we do? the least cost alternative or the logical choice? it always ends up the least cost alternative even if the logical choice is a rewrite. <doofus'/>
i like the part of a "cobol" to "C" to windows design effort. why don't you just whiteboard it it probably is simple anyways in scope being a "System 3" type of application. at least model the friggin' data and there you have it you're laughing.
Admin
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. So, they hire a bunch of Computer whizzes to write a program that can translate Cobol to C#++, allowing their new programmers to modify the code, which can then be converted back to Cobol, to be converted to C which can then be compiled and run in a C++ application/emulater, which itself is being run on an emulater written in C#++.
Brillant :)
Admin
This may not be that much of a WTF. Sometimes the switchover cost from one language to another can be prohibitive for an existing company. It might never make sense for a new entrant to use antiquated COBOL, but it might make sense to keep using COBOL.
That being said, it seems unlikely that all the costs incurred to keep using COBOL would still come in less than the switching costs, and it's likely that a complete rewrite in a current language would result in benefits for all parties involved. But, if it "works", and the company is still making money, then who are we to say?
My basic point is this: just because a language/platform is "old" doesn't mean it shouldn't be used. Often times there are other factors that make using a more current environment a better choice, but dropping a language/platform just because it's "old" doesn't make sense. Who decides what "old" is? 5 years? 10 years?
Admin
The WTF here is that any application that runs through that many layers, and "looks terrible and runs incredibly slow" can generate the phrase "it works"...
Admin
Hee hee...
Reminds me of the stupid functions I just wrote (in C#) to generate VBScript that runs dynamically inside our reporting tool... So, it's basically a verbose AST of a tiny fraction of VBScript. Not one of my better ideas.
Also reminds me of the whole story about Fog Creek writing a compiler with multiple backends for a VBScript-like functional dialect of Basic, rather than switching to a more popular language...
But then, Fog Creek seem to be making money. All hail home-grown language implementations! Hail! Hail!
Admin
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.
Admin
har har, what's even better is that this kind of approach is common practice in the automotive industry. Behind every flashy 2006 web interface you'll find some godawful screen scraping system extracting text from a terminal session to a mainframe over the worlds slowest WAN link.
And then you find out Ford employs about 10 people to load balance exchange. Full time. That's some career....
Admin
Gentlemen, layering have digivolved into a new, improved paradigm: I present to you "mega-layering". MEGALEYERON, the first of this new breed, will lay waste to your cities, evaporate your seas and play patticoat with your daughters.
(In a way, I admire these guys...)
Admin
[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]
It was definitely a good decision not to recompile. You know, a machine hour for a compiler costs eleventy billion dollars, and if you accidentally insert the object deck instead of the source deck, things can screw up big time.
Admin
I don't know what's the greater wtf... that this company is persisting on flogging a dead horse, or that people agree with the decision to do so?
The development and maintenance of an Emulator + a Cobol-C Translator alone introduces far more costs and potential problems than it would have to just move to an x86 cobol compiler, or even move to a modern language&platform. Arg do you people work in government or something?
Admin
I dunno. It seems to me that the complexity of fully functional emulator and a cobol-to-c converter would be far greater than any sort of automobile dealership application.
Admin
I wouldn't want to work there... but in a perverse sort of way I'm pretty impressed that they still have this thing working.
Admin
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.
The real WTF is that the company didn't figure this out, and already applied it twice, to get more money out of thier customers. That seems like the Enterprise thing to do!
Admin
Admin
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.
Admin
The real WTF will be when the programmers retire.
Admin
They are right.Re: No Need to Change It!
Admin
OK, at what point in time do those with the deaf ears start to retire or just die off the face of the planet, killing off the COBOL requirements?
Admin
This is not a traditional WTF, the kind where you say, "WTF?! Those iiiiiiiiiiiidiots!"
Instead, here I find myself saying, "WTF?! How did that work? Amaaaaaazing..."
captcha: random
Admin
Yeah, right. Nice example of comuter SiFi.
http://www.netcobol.com/products/windows/cobol.htm
Admin
What surprises me more are people like you who can't read. They dropped the emulator when doing the COBOL to C translator. Do you work in government?
Admin
COBOL still has its uses.
S/3 COBOL running on Windows? No.
Of course, you'll never get the geezers in the dev team to admit that, because they're not going to find jobs elsewhere. It's like Dilbert in reverse.
To be honest, though, I'd probably take the job David took, as a kind of computing anthropology study.
Admin
Yeah, what the hell has the "entire floor of cobol workers" been so busy working on the last 20 years? Are there *that* many innovations in auto dealership management going on right now? Or is it that COBOL developers are unionized?
Amazing the multiple layers at work there though. A COBOL debugger that's actually disassembling C++ instructions? Mind is having a hard time getting around that. Translating a terminal interface into a Windows interface on the fly? Once again, hurts my head.
Admin
"terminaly" <--- Hahaha.
I think its just incredible that it worked, meaning, System/3-COBOL-translated-to-C-rendered-in-Windows application.
Admin
For some reason, I don't feel that this is much of a WTF. One company I occasionionally work for still runs their legacy cobol programs on a Windows box that emulates some legacy BULL hardware. They have 1000+ users working with that system; next year, they will switch to SAP.
It's easy to say "why not port it to a newer hardware", or "why not rewrite it in Java/C#/whatever" if you are not the one to pay for that. Hundreds of man years in undocumented, hard-to-read, but time-tested cobol code are too big an investment to simply throw it away.
Admin
There are really only two big vendors in this field ADP and Reynolds & Reynolds. Both of these companies are guilty of doing everything in the WTF, so I wouldn't even venture a guess as to which one it was. Well I could because I know what hardware they run on, but that's neither here nor there.
As to competing - the big problem is that dealer management software is basically really complex accounting software. You basically have to have a system that's flexible enough to let you do all kinds of things that range from the morally challenged to the illegal. Just to start with most dealerships buy one dealer management system that they use for multiple franchieses. So for example I might have a GMC, Chevy, Hummer dealership. I would have to keep three sets of books, one for each of those franchises (well I would if I was being simple, but chances are I'd lump two together just to make things more complex). I need to be able to keep track of what I've paid for a car, but I also need a system whereby no one at my dealership can actually find out what I paid for the car, because then they might undercut profits. I need the ability to keep MSRP, and what I want the sales people to target selling the car for. I also need to be sure that I can have lots of extra price fields, because no two dealers use them the same way. And different sales people might have different prices for a car. I also need a way to keep track of at least 7 different prices for every option on the car. If you could make it so I could have two sets of books that would be ideal.
You're dealing with systems that have evolved over almost 40 years to allow all sorts of exceptional behavior. It's very hard to compete with that. Or rewrite it.
Admin
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!
Steve
Admin
It reminds me of a company in my home town. They run social security system databases for one region of a country on OLD ibm mainframe. With modem dial-ins, streamers and everything.
Yep - they still have original Digger running in the same room :)
Admin
I've seen some of these operations, so wedded to the past that they don't see that it's only a matter of time till some flexible new company blows them out of the market place.
In my younger days I did an inventory management app for a tire dealer. I worked at home in VB and MS-Jet (yes it worked with more than adequate performance for his business size), charged a comfortable hourly rate, and still gave him an executable with everything he wanted at a fraction of the old line established products. (He wanted to develop it into an actual product but was seriously injured in an auto crash and the product never materialized)
Admin
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 :)
Admin
After reading this, I tried to reply by clicking the "Report Abuse" link. Isn't that the only reasonable thing to do?
:-)
From memory I would say this.
MOVE 2006 TO CURRENT-YEAR
MOVE 1975 TO DISCO-ERA
PERFORM UNTIL CURRENT-YEAR EQUALS DISCO-ERA
SUBTRACT 1 FROM CURRENT-YEAR
END-PERFORM.
Admin
From that description, it sounds like all you need to do is hire a Excel VBA guru that can maintain 35+ spreadsheets and write crazy cool macros that handle all the "morally challenging" stuff. Security through obsfucation at it's finest...with enough similarly looking spreadsheets running around no one will be able to keep track of what spreadsheets are where and what each one is for.
Admin
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.
It was also very slow, so it could very well have been running in some sort of emulation layer, though I never bothered to look that deeply into it.
Either that, or this happens more often than any of us would really like to think.
Admin
http://www.netcobol.com/products/windows/cobol.htm
Admin
As horrible as all this sounds, there's precedent I've observed in the real world for them desiring to never change something that seems to "work perfectly" though I must admit, this goes just a bit (or 32 or 64) bits further in insanity than seems reasonable.
The details of this being anonymized leave it uncertain as to whether this is car dealership software (I've seen what appears to be old stuff in new dealerships, so it is all too plausible!) or something else like airline reservation software (you might not want to really know just how old the systems are that are used in the air traffic controller towers, as it may likely be as old as the planes you fly on, or older, and consider the US military is still using the B52 bomber from the WW2 era, with tweaks, with the original airframes - and commercial airlines are still flying passenger jets such as Boeing 747's bought when they first came out) but between being a customer at various establishments, and doing an odd job of delivering pizza when the economy sucked where I was living, I can testify that POS software used is often POS of the less complimentary acronym kind. Within the last 2 weeks, for example, I've watched the Safeway POS cash register software completely reboot the computer immediately upon scanning bananas (how fitting!) which revealed a bootup sequence that looked like a Linux mutation. Translation: el-cheapo software development, as it seems unreasonable to think that the OS itself is that crappy, so it's likely a really bad custom driver. So, too, pizza places are absofriggin'lutely horrible with their software and the quality (or lack thereof) of it, and I saw it first hand at the chain I worked (the regional manager tried to explain "It's old!" as if bits rotted for how badly it screwed up when it completely lost orders, or messed up some orders with crap data corruption, or the store system needed to be rebooted because it stopped printing at the make stations) and I know for certain in this case, that the base OS was Linux, but again, I don't blame it on the OS itself, because I know better. I distinctly remember delivering to someone that worked for another big pizza chain (last half of the name rhymes with slut) that assured me things were that bad with their systems, too, and then... I moved across the continent, to start buying pizza at a chain that's still quite new and small, that had it mangle/lose one of my orders (I really didn't like the pizza they guessed I wanted).
Having written all that, I suppose someone will ask me to submit a story for Alex to post :)
(I surprised the store manager once when I told him I remembered the bizarre 3 pizza order and whom to deliver it to when it was eaten by the computere, and I ended up being correct)
Admin
Stop POSTING!
Admin
We all want the perfectly flexible system that can handle changes with a few new parameters. But sometimes it's easier to just keep programmers on staff and code up exceptions as they come up.
Admin
This would be funny if the company I'm working with weren't doing exactly the same thing. 'Cept in my case the perversities of choice are PICK BASIC , TN4 and Universe. The real WTF is that here they ARE rewriting there systems - from TN4 to the Windowsesque terminal emulation bull described above - and this is in 2006.
The real cherry on top of this particular crapcake is the fact that these software terrorists have visions of building an SOA using pick basic.
Hah, hah,hah, hah, hahahaaaaa... (descending into hysterics)
Oh God, counting down the days to the end of this contract....