- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- 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
Sidenote - how come only SOME posts have "report abuse" links? Are some users pre-screened and certified Abuse-Free?
Admin
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.
Admin
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.
Dang! Computin' was fun back then! :-)
Admin
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.
Admin
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).
Admin
My innards have just become my outards. Anyone have a tissue? Captcha = paste :-)
Admin
Someone seems to have missed a joke.
Admin
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.
Admin
Didn't anyone do a proper ROI?
Admin
Yeah that part kinda puzzled me too.
Admin
Until MS no longer supports XP ...
Admin
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
Admin
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?
Admin
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.
Admin
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.
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.
Admin
you left out our clever nickname for the cobol crap with windows forms project
"cobol foundation classes" (a rip on MFC, microsoft foundation classes)
Admin
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.
Admin
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.
Admin
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.
Admin
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.
Admin
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.)
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.
Admin
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 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.
Admin
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?
Admin
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.
Admin
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.
Admin
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.
Admin
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 ...
Admin
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".
Admin
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.
Admin
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.
Admin
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 :)
Admin
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."
Admin
(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!!???
Admin
What, and admit this story is about them?
Admin
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.
Admin
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.
Implementing callbacks in any language only requires three things:
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
Admin
Didnt read all the posts, but, unh...just wait till Vista hits these guys...
CAPTCHA: perfection
Suitable I guess
Admin
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.
Admin
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!
Admin
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...
Admin
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!
Admin
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
Admin
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.
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."
You are Pham Nuwen and I claim my Deepness in the Sky.
Admin
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?
Admin
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:
Admin
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.
Admin
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.
Admin
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!!
Admin
Was that company's name "AutoSoft?"