A Load Of Old Cobols
-
Comments posted to this topic are about the item A Load Of Old Cobols
-
Heh... forget the old stuff. It'll persevere and someone somewhere will know how to fix it or be able to science it out. It's a part of why it's lasted so long.
It's the new stuff that I worry about, especially since new stuff has a habit of going away much more quickly than the old stuff if not for one reason, then another. Then, there's the problem of no one actually knowing how to use the new stuff correctly, being buggy, constantly under upgrade, etc, etc.
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
Sounds too familiar. I wrote a database frontend in VB6 in 1998 or so, and the software has been in continuous use by up to 150 users in several small nonprofit organizations since then (although now it’s down to 20), with lots of changes and customizations along the way. The problem is that the VB6 dev environment won’t install (at least for me) on anything later than Windows XP. So, there it is, installed on a 2005 Pentium computer sitting in a corner, that I don’t power up unless a modification is needed (maybe twice a year). The last modification was to move the database to MS Azure a few months ago – and I admit to some surprise when the VB6 code connected flawlessly. I can’t use another XP machine as a backup environment because the software used a proprietary VB6 component that is now orphaned and for which I can no longer get a one-use install/distribution code, so it can’t be added to a fresh Visual Studio installation. At some point, I’ll find a week to rewrite it as a web app (it’s not very complicated). I guess cloning the drive or virtualizing the machine are also options, but at some point we should draw a line.
-
I too wrote database backends in VB6 around that timeframe (late 1990's) and am still maintaining them. My latest "re-install" of VB6 was Win7 Pro, the previous one was several years ago also on Win7. My biggest issue with this last Win7 install was that it was x64, and some of the VB6 (and windows) TLB's did not register properly. A couple of special tools I was using I had to "manually" install module by module. But VB6-32 as a development tool is still alive and kicking on Win7, and I suspect also when I finally migrate to Win10.
The sad part is that as others have said the "new" technologies don't tend to stick around like the older ones did, and Microsoft is one of the major offenders in this arena, although Google is becoming a close second.
I suspect .NET will be around for a few years more, just like so many previous Microsoft technologies, but only until their next greatest-ever invention.
So in relation to the original topic, there is good reason for older technologies to survive, they were the best available at their time, and in many cases they provide (almost) mission-critical applications that are serving their original design purpose, and the cost of re-working them into a new environment just for the sake of having them in that new environment in many cases is just not justifiable, the risk to the organization is significantly bigger that the benefit to be gained.
I recall many years back (during the cobol eras) when I was maintaining and extending applications in IBM assembler, for exactly the same reasons, an example being a very large mission-critical application for a cable billing system.
So these systems will always be around and we who are able to maintain them are getting fewer and fewer. Educational institutions don't teach these, heck even the SQL some places are teaching is crap when you get into the real world. More than once over the last few years I have asked a newbie why he did something that way, the answer has always been "that's the way they taught me" 🙁
-
Frankly, what I find is that there are too few of any of the "new kids on the block" that ever troubled themselves to learn or understand the "old ways". They aren't so esoteric that one couldn't deconstruct the programs and replace them with new languages and objects. Even if its Cobol...or even just Access.
In fact, the usual paradigm is that "business analysts" attempt to do the deconstructing and write specs for the "new kids". The tech analysts can't understand the old stuff, and the coders won't be bothered going over it.
And thus the dominance of Cobol programmers continues. Probably more a failure of management than some magical quality of the old coders...
-
I'm pretty much retired now, so I don't have this problem any more except in the form of having some archaic stuff that won't run on windows 10 and I haven't yet decided whether just to junk that stuff or organise myself something to support it. However, I did have that problem it seven years ago.
In 2009 I was still running product development mostly using Javascript with ASP 3.0 (not ASP.NET) and SQL Server 2000, and really horrible 1980s technology (C++) that had been technologically out-of-date since before it first shipped (I find it amazing that people are still using that truly awful language), while supporting the product for customers on anything from Windows 2000 Server to Windows Server 2008 R2 and client PCs running a very very very much chopped about Windows XPe. The worst support problem was CISCO BBSM which was still used by one or two customers (that included the 2001 version of MSDE running of some form of Windows 2000, and CISCO had built that system so that new SQL Server service packs could NOT be applied; I'd taken it apart and put it together again for that reason amongst others, but the CISCO siftware was still effectively a heap of junk, a real time comms processor with hordes of unresolved race conditions that CISCO wouldn't fix and I didn't have the source code of, and an API in JScript for building its interface to the host system where those race conditions were intoleable). So definitely a lot of ancient stuff that needed replacing.
I had already set up a new development team in Beirut to take over development and 2nd and 3rd line support and move the product onto modern technology - SQL Server 2008, Microsoft Presentation Foundation, ASP.NET, .NET Framework 4 (which was then in Beta) - they were now handling most development and all the middle east customer support. The idea was that we could close down our technology and engineering operations in London, so that I could retire and my Beirut-based successor would become Technical Director and most senior employee, and would soon escape from all the ancient technologies.
Tom
-
Two points about old code:
I started writing COBOL back in 1969. In those days there seems to have been a fair demand for programmers and lots of them were new to the field and the skill. COBOL has always been put down as a bad product, but I think the real problem was bad COBOL programmers. By its very nature, COBOL could be written by folks who had absolutely no understanding of what was really happening 'inside the box' in terms of the operations that the compiler would turn their code into.
Second, the existence of this old code in 2016 is indicative of poor management that has allowed it to exist and outgrow the safety of using it, and exposing their companies to the cost of the highly paid personnel to maintain and modify it for them.
One of the last capabilities that I learned in COBOL was the ability to create what was actually highly structured code. Without it, we would never have been to understand systems of hundreds of thousands of line of code with program listings of 50 to 100 pages of code - yes, pages, since we still on occasion produced printed program listing on which we noted and dated changes so we didn't have to re-print them.
Since I did not actually USE any COBOL code after my first few years, I am not aware of what expanded capabilities might have been added to the base, but I suspect possibly the capabilities of this old code might be constraining the companies of making advances in the options for making use of information.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) ) -
I haven't been in the workforce for a long time, but the first systems I started messing with when I was 15 years old were old Unix-based systems. I programmed in C on Multi-User Dungeons (MUDs) that were originally created in 1993-1995. The origins of this system dated back to 1978 when a student at Essex University in the UK, started working on a multi-user adventure game in the MACRO-10 assembly language for a DEC PDP-10.
Working on a directive of these engines called ROM allowed me to learn about programming and online applications that supported multiple users simultaneously. This eventually led me to databases that had to support the content and the users of these games, which was no easy task back in those days due to the high amount of transactions per second that was needed to log every step a user made in the application.
In the work place, I haven't really been to exposed to too many legacy systems outside of some older MS Access setups that had custom VBA modules designed for ETL and reporting. Those were pretty scary though. 😛
-
I occasionally encounter SQL that was originally coded back in the early '90s, even though it has been migrated to newer hardware and RDMS platforms several times since. The way I see it, back office programming like COBOL and SQL are like the plumbing behind the wall; it must be professionally done, and it should be built to last.
In contrast, front end stuff like SilverLight, JavaScript, and Tableau are like the paint on wall; you can hand the job over to an intern, and regardless of how functional the end result may be, it will just end up getting tossed for something new in a few years for aesthetic reasons.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
-
Eric M Russell (10/17/2016)
I occasionally encounter SQL that was originally coded back in the early '90s, even though it has been migrated to newer hardware and RDMS platforms several times since. The way I see it, back office programming like COBOL and SQL are like the plumbing behind the wall; it must be professionally done, and it should be built to last.In contrast, front end stuff like SilverLight, JavaScript, and Tableau are like the paint on wall; you can hand the job over to an intern, and regardless of how functional the end result may be, it will just end up getting tossed for something new in a few years for aesthetic reasons.
Eric, you nailed it with your concept of 'back office programming'. It's the important part that makes all the pretty frontend stuff do it's job. It's important that the backend have the features and capabilities to get the real grunt work done.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) ) -
Eric M Russell (10/17/2016)
I occasionally encounter SQL that was originally coded back in the early '90s, even though it has been migrated to newer hardware and RDMS platforms several times since. The way I see it, back office programming like COBOL and SQL are like the plumbing behind the wall; it must be professionally done, and it should be built to last.In contrast, front end stuff like SilverLight, JavaScript, and Tableau are like the paint on wall; you can hand the job over to an intern, and regardless of how functional the end result may be, it will just end up getting tossed for something new in a few years for aesthetic reasons.
That's a great analogy, Eric.
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
Heh, I read the last sentence about business-critical logic being stored "in Access on an old laptop in a cupboard somewhere", and my mind immediately substituted that with "in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard.'" 😀 RIP, Mr. Adams...
-
VB6 and even FoxPro applications still thriving and multiplying in some IT shops despite having no evolution in it's digital DNA for almost 20 years.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
-
I was aghast to find an old Clipper app still being maintained, although it didn't really need much maintaining. For next to no investment it was cheerfully generating £2million per year!
I can't help thinking that the IT industry is one gigantic con trick aided and abetted by it's customers in much the same way that the diet food industry is aided and abetted by the obese.
No one in business will thank you for saying "look, if you just altered your business processes you could do more with less". Believe me there is a business equivalent of tech debt.
The reality is that hardware has exceeded the power required by most business applications. The evidence for this is virtualization.
What exactly are the new tools and frameworks adding beyond lines on our CV?
Why agonise over the"best" technology choice? By the time you have reached the level of proficiency where any difference becomes relevant it'll be obsolete anyway!
IT religious wars abound and it seems as if the open-source ethos is to create yet another divergent fork then spin it off as a separate product rather than get the fix committed to the trunk.
-
David.Poole (10/17/2016)
I was aghast to find an old Clipper app still being maintained, although it didn't really need much maintaining. For next to no investment it was cheerfully generating £2million per year!I can't help thinking that the IT industry is one gigantic con trick aided and abetted by it's customers in much the same way that the diet food industry is aided and abetted by the obese.
No one in business will thank you for saying "look, if you just altered your business processes you could do more with less". Believe me there is a business equivalent of tech debt.
The reality is that hardware has exceeded the power required by most business applications. The evidence for this is virtualization.
What exactly are the new tools and frameworks adding beyond lines on our CV?
Why agonise over the"best" technology choice? By the time you have reached the level of proficiency where any difference becomes relevant it'll be obsolete anyway!
IT religious wars abound and it seems as if the open-source ethos is to create yet another divergent fork then spin it off as a separate product rather than get the fix committed to the trunk.
Wow, David. You absolutely blew me away with that rant. Just wait until your company comes and says they need something and need it quickly, and see what they do when your reply is 'You can't get there from here'. About the only thing I can agree with is your comment that 'hardware has exceeded the power required by most business applications'. It's true that one does not always need all the available power, just the needed power. And it is your responsibility to determine what is needed and get it for them.
If you have allowed things to get so far out of date that you can't react, you have failed.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
Viewing 15 posts - 1 through 15 (of 39 total)
You must be logged in to reply to this topic. Login to reply