Die COBOL... Die!!
-
I think the real question is why anyone would want to make an "object oriented" version of COBOL. I have been programming for 30+ years now, and I can't count all the wonderful innovations I have seen come and go. Exactly one of them -- structured programming -- was actually an advance over what went before. I am sure this will ignite a firestorm of rage and recrimination, but as far as I can see, OO is a fancy shmancy name for wasting a whole lot of time dancing around before you design your data structures and subroutine libraries (OOPs, I mean "classes" and "methods"). There is really nothing you can do with Oh-Oh that you can't do with a good assembler. Well, I should qualify that. Nothing useful. Obviously, there is always money to be made selling old wine in new bottles. I have learned and forgotten a Babel of languages, and at this point what I want from a language is for it to Get Out Of The Way and let me work on the problem. Visual Basic comes closest, so naturally they are pulling the plug on it.
I never had trouble by having too much tools to use. I had trouble when my toolbox have nothing but old tools that don't meet the today's requirements. Sure I can always make "new" tools based on the old ones but will they ever be actually considered new? :doh: On the other hand, there's people that when have too many tools on their disposal try to use them all on a single job, even if that job only required half of the do be well done. There's still a third scenario... those illuminated people who invent new tools and the have to invent a way of using it somewhere. On this last scenario usually lies most of the tech hypes that come and go and most of us with some years around didn't even cared about.
-
There's nothing that can be expressed easily in Cobol, as far as I remember. You quite obviously have no ability for simple things that work do you. I never had a problem in COBOL, and I don't have problems in other the other languages that I picked up when I moved on to other jobs. Cobol is simple, its powerful, and it doesn't use crap gui's that waist cycle, bandwidth power. Get a life, quit being a jealous cry baby. Dan
Absolutely. One really must remember that everything has its own place and purpose. Event-driven models, forced to sit behind/in a gui framework, just do not fit transactional processing. Remember, transactional processing is back-office, streams of items in, process, filter, archive, and out - stuff that procedural languages COBOL/PLI/ALGOL/FORTRAN/C - can do extremely well and concisely - all with little fluff, transfer vectors for each instantiation, etc., etc. Sometimes it is appropriate to apply structure, abstraction, dynamic binding, etc, to transactional processing - implementable readily in C (and even COBOL with a little preprocessing) - but that is only structure and expression. That does not make COBOL any more appropriate for events driven by HUMAN interaction, nor C++/Net appropriate for transactions. chrysg
-
Thanks for the COBOL explanations. I had no idea about how it was implemented in COBOL.
ghle wrote:
All is done in integer arithmetic, with the decimal point normalized as required. Explaining why is normally an exercise in frustration.
BTW, Why? :doh: Decimals always worked fine for me... never gave me any problems. Floats are a pain when 10-1.5 can lead you to 8.499999999999999999999999 X|
AlexCode wrote:
BTW, Why?
- It's 100% accurate. 2) It's faster. 3) No rounding problems. 4) Smaller storage requirements. Floating points, like integers, are stored as binary, not decimal: 1/2, 1/4, 1/8, 1/16, 1/32, 1/64, etc. So 8.5 is stored perfectly as 8 + 1/2.:omg: But 10 - 1.89 I can see. 8 + 1/16 + 1/64 + 1/128 + 1/256 + ... (ouch, brain cramp) So you can see, financial accounting requires intimate knowledge of the underlying data storage and operations unless the language compensates for you. You can have errors in only a couple decimal places. Multiplying and dividing inaccurate numbers only compounds the effects. You end up with an inexact result. If the language can do math perfectly, you don't have to worry about which results might be inaccurate because there are none. You only have to worry about rounding the final result to pennies, which the language can do for you automatically, also. Gary
-
Great, but just as important is at least 1 year of VS 2008. :rose: Please send the perfect resume and salary requirements to HR@IWontContactYouAtAll.com. No phone calls please. :^) Gary
-
Talking on another thread we end up talking about COBOL and finding that IBM (at least) if developing a OO version of this ancient language. The very first question is: WHY? Shouldn't it be easier to learn/use a new good OO language instead of reinventing the wheel on some prehistoric (1950) concept? What should be worst: * Converting COBOL code to another language (I don't mean reverse engineer it, grab the business logic and recode the whole thing)? * Recompile it somehow (thinking that this OO version is somehow backwards compatible) with a OO facelift compiler but stay in the mud? I don't know... this feels like a very few group of people (compared to the developers community) trying not to loose their jobs and keep earning too much money developing and patching restrictive, but most very important, software. Here I leave some links: http://home.swbell.net/mck9/cobol/ooc/ooc.html Hurts my fingers to publish this link... You may also get nasty about this one (COBOL on .net): http://www.dotnetheaven.com/Articles/ArticleListing.aspx?SectionID=16
It's been many years since I coded COBOL on a Univac 1106 but as I remember, COBOL actually had a self-modifying code statement. If memory serves me correct it was something like: Modify [Paragraph Name] to proceed to [Paragraph Name]. You probably ask yourself why. Well in those days it took a CPU much longer to perform a "If (boolean expresion) ..." than a jump (and probably still does). So what we write today as: void SomeFunc() { static bool FirstTime = true; if (FirstTime) { ... ... FirstTime = false; } ... ... } with the (boolean expression) ALWAYS being evaluated. But the COBOL code does not: ... ... Paragraph-Name1 Goto Paragraph-Name2 Paragraph-Name2 ... ... Modify Paragraph-Name1 to proceed to Paragraph-Name3 Paragraph-Name3 ... ... This COBOL code accomplishes the exact same result as using a "first time" flag but with less CPU time. That was important when processing millions of utility bills for month-end billing and processor speeds where not measured in GHZ. All you good COBOL coders out there, forgive me if I don't have the exact syntax, but regardless COBOL did offer the ability to modify its code at run-time.
-
AlexCode wrote:
BTW, Why?
- It's 100% accurate. 2) It's faster. 3) No rounding problems. 4) Smaller storage requirements. Floating points, like integers, are stored as binary, not decimal: 1/2, 1/4, 1/8, 1/16, 1/32, 1/64, etc. So 8.5 is stored perfectly as 8 + 1/2.:omg: But 10 - 1.89 I can see. 8 + 1/16 + 1/64 + 1/128 + 1/256 + ... (ouch, brain cramp) So you can see, financial accounting requires intimate knowledge of the underlying data storage and operations unless the language compensates for you. You can have errors in only a couple decimal places. Multiplying and dividing inaccurate numbers only compounds the effects. You end up with an inexact result. If the language can do math perfectly, you don't have to worry about which results might be inaccurate because there are none. You only have to worry about rounding the final result to pennies, which the language can do for you automatically, also. Gary
-
It's been many years since I coded COBOL on a Univac 1106 but as I remember, COBOL actually had a self-modifying code statement. If memory serves me correct it was something like: Modify [Paragraph Name] to proceed to [Paragraph Name]. You probably ask yourself why. Well in those days it took a CPU much longer to perform a "If (boolean expresion) ..." than a jump (and probably still does). So what we write today as: void SomeFunc() { static bool FirstTime = true; if (FirstTime) { ... ... FirstTime = false; } ... ... } with the (boolean expression) ALWAYS being evaluated. But the COBOL code does not: ... ... Paragraph-Name1 Goto Paragraph-Name2 Paragraph-Name2 ... ... Modify Paragraph-Name1 to proceed to Paragraph-Name3 Paragraph-Name3 ... ... This COBOL code accomplishes the exact same result as using a "first time" flag but with less CPU time. That was important when processing millions of utility bills for month-end billing and processor speeds where not measured in GHZ. All you good COBOL coders out there, forgive me if I don't have the exact syntax, but regardless COBOL did offer the ability to modify its code at run-time.
Seeing the COBOL syntax I can see why it was adopted compared to C for example. It's a verbose syntax that you write as you speak. The same reason that later on gave so much popularity to VB for example. Understanding the so deep differences makes me even more reluctant about a COBOL OO or/and .net version
-
First things first, I never meant to disrespect nothing or anyone.
cjbauman wrote:
older versions or types of the tools we use to build the software we get paid to build
This is my point... you put this in the past when you say "we use to" but my point is exactly why is it still being implemented, why are still new applications being developed on it, and why the effort of upgrading it to OO at this time?
cjbauman wrote:
Let's not disparage the old tools or the workers just because the trade has evolved and some things (not all) are easier to do with the new tools.
You're right until the point when maintaining the old house is more expensive than building a new one. This idea isn't correct for every COBOL implementation but I'm sure it will be good for most. I'm well convinced that converting a COBOL application to C# for instance is as hard as if it was FOX Pro instead of COBOL. Most problems rely on the lack (usually complete absence of) application business logic documentation not on the greatness of this or that language.
AlexCode wrote:
you put this in the past when you say "we use to"
Uh, actually, not. If I had said "we used to use", that would've been past tense. There are references to the past in my post but this isn't one of them. ;) I guess I need to clarify what I was objecting to in my post. Two things and two things only: 1) The notion that a comparison of dinosaurs to Porsches was somehow an appropriate metaphor of the differences between COBOL and more modern languages. It's not and never has been. Dinosaurs were animals not cars. When you compare dinosaurs and Porsches you're comparing representatives from 2 completely different categories. COBOL is not in a completely different category from C#, it's merely an older tool used for the same purpose as C#; creating software. Of course, there's also the fact that dinosaurs no longer exist whereas COBOL obviously does. :-D My objection was only to the error in reasoning represented by the comparison. It was not to the notion that most current software development should be done using the best tools available. 2) What I saw as the implied disparagement/disrespect towards people who do work or have worked in COBOL. That part wasn't even addressed directly to you, if you'll review my post. At the time I was referring to postings from others but apparently you saw yourself in it since it was the first thing you addressed in your reply. I wasn't pointing fingers; just weighing in against an attitude I run into all too often these days from those I consider to be newbies. I guess this is a hot button for me, but I'm just plain tired of hearing people who (seem to) have no historical perspective and little (apparent) knowledge of the realities of how platform purchasing decisions are made in corporate America (or wherever) devalue the contribution of developers who worked well in technologies that they usually didn't have much choice about but that were, usually, state of the art at the time. Worse than that is the notion that COBOL is somehow still being kept around because the COBOL developers are stuck in their rut and refuse to change. The vast majority of us are/were not making budget decisions and are/were not really heard by those that do. I admit I don't really know what's being taught in universities today but classically trained software developers learned to see the choice of development tool(s) as something yo
-
I've gotten such a good laugh reading this thread. I was relatively late on the COBOL programming scene. I started programming COBOL and Fortran in 1972. I really don't remember C being an option until the 1980s. :-D COBOL is/was a great language because anyone could be taught it. That didn't make them good programmers, but it did exactly what companies needed. Lots of warm bodies that could write code. Very much like today's modern(?) languages, almost anyone can learn them but the majority of today's programmers are just as bad as yesterday's COBOL programmers. It's not the language that is crappy, it's the people that think they can code. I've learned a number of other languages since my COBOL days, IBM Assembler, C, C++, Powerbuilder, VB, SQL, Actionscript, to name a couple. The really amusing part is that I see programmers making the same types of errors over and over. You get a spec if you're lucky, you start coding, you do some quick testing to make sure that it does what you think it should and then move on. There was a saying that I read years ago. 95% of all programmers should flowchart but only 5% do. That's why we have so many crappy programs, that perform badly and need constant maintenance. Not because the languages we program in are bad, it's because programmers don't learn the languages well enough to express the problem clearly. Anyone remember COBOL's "Alter goto?"
Rob954 wrote:
Anyone remember COBOL's "Alter goto?"
Ugh! Yes, but, thankfully, in most COBOL shops I worked in, the nasty beast didn't make it through code review because it was specifically proscribed by published coding standards. Of course, published coding standards seem to be a rare thing these days, too.
-
AlexCode wrote:
Do you have an explanation why it isn't more implemented?
I think, in fact, it's implementation is more widespread than C#, Visual Basic, or other recent languages. It's staying power is a combination of it's ease of use, raw power for data manipulation, usefulness in it's applicable areas. One of the side effects of Cobol is that it is more easily self-documenting than "modern" languages, so this helps sustain the code base that is out there. [One can write as arcane a Cobol program as a C program, but that is not the tendency.] In scientific, Client-Server and graphical areas it is not a fit, and a lot of today's newest development is in these areas. Developers with the mind-set to do this type of development, puke when they see Cobol. As one with experience in MicroCode, Machine Code, Assembler, C, Pascal, Basic, HTML, TCAL, COBOL, RPG, Visual Basic, C++, EVC++, PHP, ASP, XML, Java Script, Java, .Net, etc. I see merits in each one. But in the end, they are all just tools to help twiddle bits. RPG - Another language that should die off, but to write a report, it's quick and easy. HTH Gary
-
AlexCode wrote:
you put this in the past when you say "we use to"
Uh, actually, not. If I had said "we used to use", that would've been past tense. There are references to the past in my post but this isn't one of them. ;) I guess I need to clarify what I was objecting to in my post. Two things and two things only: 1) The notion that a comparison of dinosaurs to Porsches was somehow an appropriate metaphor of the differences between COBOL and more modern languages. It's not and never has been. Dinosaurs were animals not cars. When you compare dinosaurs and Porsches you're comparing representatives from 2 completely different categories. COBOL is not in a completely different category from C#, it's merely an older tool used for the same purpose as C#; creating software. Of course, there's also the fact that dinosaurs no longer exist whereas COBOL obviously does. :-D My objection was only to the error in reasoning represented by the comparison. It was not to the notion that most current software development should be done using the best tools available. 2) What I saw as the implied disparagement/disrespect towards people who do work or have worked in COBOL. That part wasn't even addressed directly to you, if you'll review my post. At the time I was referring to postings from others but apparently you saw yourself in it since it was the first thing you addressed in your reply. I wasn't pointing fingers; just weighing in against an attitude I run into all too often these days from those I consider to be newbies. I guess this is a hot button for me, but I'm just plain tired of hearing people who (seem to) have no historical perspective and little (apparent) knowledge of the realities of how platform purchasing decisions are made in corporate America (or wherever) devalue the contribution of developers who worked well in technologies that they usually didn't have much choice about but that were, usually, state of the art at the time. Worse than that is the notion that COBOL is somehow still being kept around because the COBOL developers are stuck in their rut and refuse to change. The vast majority of us are/were not making budget decisions and are/were not really heard by those that do. I admit I don't really know what's being taught in universities today but classically trained software developers learned to see the choice of development tool(s) as something yo
Mate... thanks a lot for the answer effort. I think we must discuss more things more often :-> You're right about the dinosaur -> Porsche comparison, it was unfortunate. May I replace the dinosaur by a Fiat 126? ;P
cjbauman wrote:
if IBM didn't think they had a market for the OO COBOL product you referred to, they wouldn't be developing it
This is one way of thinking, but we may think that keeping their development on a more "closed" development language they also keep their monopoly. Adopting a broader and more implemented language would put some risk on that monopoly. Lets face it and replace it by the extreme... VB! How many people would be able to learn VB in a way to be able to support IBM customers on the side? How many are already able to do it today? Compare the number with the ones able to do it today with COBOL...
cjbauman wrote:
The COBOL code base that exists is primarily in shops that support non-technology businesses
Knowing well the Portuguese market, COBOL is mostly implemented in the banking and heavy industrial areas, supported mostly by IBM. I don't question why this was adopted some years ago, I never did, and my line of thinking when dealing with a existing software is that if it works, and fulfills all or almost every requirements we should keep it. Reengineering the whole thing is very expensive and doesn't warranty better results than the old implementation in short time. I'm always questioning why is it still being used in new implementations and why the effort of trying to make it something good when there are already so many better things available. Again, many thanks for your participation on this thread. Nice talking to you. Cheers! Alex
-
That's undisputable! A boss of mine teached me Cobol with this words: "Cobol has four instructions: READ, WRITE, MOVE, IF. Or at least, these are the ones you're going to use" I felt a little worried... (more about my boss, though) He never used the power of COBOL then. There was even in the beginnings much more powerful statements then that. Perform to ultimate levels, tables to ultimate levels, case statement. Long before VB ever thought of them. I have no simpathy for repeated blocks of code that do exactly the same thing ("Mantainability, whatever the heck is it?") Not to speak about the compiler/interpreter bugs: I know that even MS.NET has even more bugs, but it's a much younger environment whem compared to Cobol ones. If that is how you code, then your coding skills are bad. I never used repeated blocks of code. You don't have to if you know how to do structured programming. Sorry, that is coding skill that cause's repeatable blocks of code. Not the language. And with your OO abilities in COBOL, which have been there for years. You have made no point at all in this statement. None. That's totally false: id depends on the operating system you're running the Cobol interpreter, it's not a language feature: Cobols for Windows actually use [crap] gui. You (and I, for that matters) may like it or not, but people is accustomed to use Windows or Macintosh or Linux/XWindows software, not Unix System V Release command line interface based software. Cobol wasn't developed for winblows. It was developed for main fraim computers that push large volumes of transactions and data. I wouldn't use COBOL on any server, that isn't it's strong point. And for you to even sugest that shows how little you actualy understand WHY it was developed. By the way, ever hear of a database? IMS, DB2? Who use's flat files? Except in some type of interface to populate a database. Again, your coding skills are not making a very impresable showing right now. Dan
droolin wrote:
You don't have to if you know how to do structured programming.
It's clear I was not... clear: when I spoke about repeated blocks of code I wasn't thinking about things you can do with loops and that strange thing called recursion (I remember they taught me something about at the little chimp pre-school); I was thinking about repeating the same blocks of code for the sections defining the data structures: if you have several programs accessing customer data (flat file of database) you had to copy the same data definition structures (manually or via an include statement, COPY I think - yes I know: I am not able of thinking!) and to recompile each one of them and redistribute each new compiled .obj file (if I remember well - yes I know, remebering is an activity of the brain, and I definetly don't show evidences of having one). I could say that it wasn't my personal fault, that I worked in such a shop of stupid and short-sighted people who taught me little things I wasn't able to criticize because of my deficiences : but, in my so ignorant opinion, that's not the point. The real point is that there's nothing I can say without offending you personally, and I didn't mean to do that: I just meant that I don't like Cobol exactly the same way I don't like ties or cigarettes (they are unrelated: I'm stupid, but not so much), though I have nothing against people who use ties or Cobol. I'm sorry having offended you so much, I do apologize and take sure I'll never do it again. Have a nice day
Marco Turrini
-
droolin wrote:
You don't have to if you know how to do structured programming.
It's clear I was not... clear: when I spoke about repeated blocks of code I wasn't thinking about things you can do with loops and that strange thing called recursion (I remember they taught me something about at the little chimp pre-school); I was thinking about repeating the same blocks of code for the sections defining the data structures: if you have several programs accessing customer data (flat file of database) you had to copy the same data definition structures (manually or via an include statement, COPY I think - yes I know: I am not able of thinking!) and to recompile each one of them and redistribute each new compiled .obj file (if I remember well - yes I know, remebering is an activity of the brain, and I definetly don't show evidences of having one). I could say that it wasn't my personal fault, that I worked in such a shop of stupid and short-sighted people who taught me little things I wasn't able to criticize because of my deficiences : but, in my so ignorant opinion, that's not the point. The real point is that there's nothing I can say without offending you personally, and I didn't mean to do that: I just meant that I don't like Cobol exactly the same way I don't like ties or cigarettes (they are unrelated: I'm stupid, but not so much), though I have nothing against people who use ties or Cobol. I'm sorry having offended you so much, I do apologize and take sure I'll never do it again. Have a nice day
Marco Turrini
I consider COBOL a strong language for the purpose it was developed for. Moving and manipulating large amounts of data on a main frame without a gui interface. It was never intended for any other purpose then that. We could get into the finer points of how coding could and should have been done. Personally, I have not found a language that is as friendly and flexible as COBOL is when it comes to tables and the defining of them. But, that could be ignorance on my part of not knowing all the finite of other languages as I use to know COBOL. With regard to the copy statement, as much as you think it is repeated lines of code. The reason I always considered it an asset and not a liability is for the simple fact that I could look in any given line of code of any program, and know that this file/database was defined the same way. That the variables being used were the same everywhere. They were standard. I also knew that if this included definition went through the code review, that the data definitions were done correctly whereas I can't always count on that when each coder defines his own. But, you are correct. They are repeated blocks of code. Which again you are correct, would require recompile if they ever changed. Again, I apologize for being so thin skinned. Dan
-
Talking on another thread we end up talking about COBOL and finding that IBM (at least) if developing a OO version of this ancient language. The very first question is: WHY? Shouldn't it be easier to learn/use a new good OO language instead of reinventing the wheel on some prehistoric (1950) concept? What should be worst: * Converting COBOL code to another language (I don't mean reverse engineer it, grab the business logic and recode the whole thing)? * Recompile it somehow (thinking that this OO version is somehow backwards compatible) with a OO facelift compiler but stay in the mud? I don't know... this feels like a very few group of people (compared to the developers community) trying not to loose their jobs and keep earning too much money developing and patching restrictive, but most very important, software. Here I leave some links: http://home.swbell.net/mck9/cobol/ooc/ooc.html Hurts my fingers to publish this link... You may also get nasty about this one (COBOL on .net): http://www.dotnetheaven.com/Articles/ArticleListing.aspx?SectionID=16
I started out as a COBOL developer in 1996, and used it for 5 years. Then I moved to VB, which I have used for the last 7 years. My current company has two versions of the same payroll software package, one pure COBOL, and one mostly VB, but with the core processing still done in COBOL. The VB system is my baby, but ... For a start, most of our customers are highly resistant to moving from the old system to the windows version. Their reasons are basically as follows: Unmatched processing speed. A large payroll run with 20 thousand employees would take all night in the windows system. The old system pumps it out in a few hours. Stability. COBOL just runs. Printing. COBOL prints using the printers built-in text fonts, which print really fast. Plus has anyone ever tried to set up a line impact printer in Windows? Did you enjoy it? Stability v2. Which would you prefer, a system developed over 30 years, starting small and gradually growing more complex. Or a GUI package based on the first system and migrated over 5 years? The second obviously being more dynamic, complex due to the GUI, and with 25 years less beta testing? Data ownership. COBOL data files are stored encrypted on your hard drive. Convincing someone that they should relinquish control to the SQL/network administrator is tough going. Piracy. It's much easier to illegally copy the COBOL system. The Potty 1
-
I consider COBOL a strong language for the purpose it was developed for. Moving and manipulating large amounts of data on a main frame without a gui interface. It was never intended for any other purpose then that. We could get into the finer points of how coding could and should have been done. Personally, I have not found a language that is as friendly and flexible as COBOL is when it comes to tables and the defining of them. But, that could be ignorance on my part of not knowing all the finite of other languages as I use to know COBOL. With regard to the copy statement, as much as you think it is repeated lines of code. The reason I always considered it an asset and not a liability is for the simple fact that I could look in any given line of code of any program, and know that this file/database was defined the same way. That the variables being used were the same everywhere. They were standard. I also knew that if this included definition went through the code review, that the data definitions were done correctly whereas I can't always count on that when each coder defines his own. But, you are correct. They are repeated blocks of code. Which again you are correct, would require recompile if they ever changed. Again, I apologize for being so thin skinned. Dan
Woah, I'm nearly fainting... I'm correct:-D (yes, about such a little issue, of course) I do agree that Cobol has been developed for specific purposes; after all, there were some reasons if it was named COmmon Business Oriented Language. And in some previous message, I said that a good Cobol programmer will sure do a better job (a program working better and easier to read and mantain, even by other people) than a bad (or even average) OO programmer: it's the human factor, not the tool which makes the difference. Things always have another side: the copy statement is either an asset and a liability, and it's up to you (the human factor) to take advantage of the asset and reduce the payload of the liability. In my previous experience this has been a big liability because whenever I was told to update module XXX, they always forgot to tell me the complete list of the module using (say) the invoices data: I know, an human error was the definitive guilty of my pain. At least, OO reduces (not to zero, of course) this possibility of error just by considering objects like black boxes: you aren't allowed to look inside of them, you aren't allowed to damage them, you know what you can expect: of course, it's up to the human factor to make this an asset or a liability. Again, I remember writing (including or copying) then same lines of code to skip one record ahead of the table: I had to write a READ-NEXT-xxx for each table the program used (READ-NEXT-CUSTOMER, READ-NEXT-INVOICE, READ-NEXT-ITEM, READ-NEXT-CURRENCY...),a READ-FIRST-xxx, a READ-PREVIOUS, and this was repeating code: the asset is that if you (ok, I, didn't mean to offend) write a bug in a READ-NEXT routine this bug would not affect any other READ-NEXT routine; the liability is that a bug could be very hard to find (the worst scenario is when you have several different bugs in rarely used routines: I spent half of my salary in medicines). On the other hands, OO helps you writing a base class to access data a minimal set of common properties and methods and then deriving from that class for the proper behaviour tipical of that object (data table, roughly): the liability is that if you write a bug in a general routine, you corrupt every table in your application; the asset is that it's generally easier to write tests, find and debug things. I'm not interested too in discussing each fine detailed: I just mean that Procedural Programming and Object Oriented Programming use two slightly different point of views. To put in just few words, the former
-
I started out as a COBOL developer in 1996, and used it for 5 years. Then I moved to VB, which I have used for the last 7 years. My current company has two versions of the same payroll software package, one pure COBOL, and one mostly VB, but with the core processing still done in COBOL. The VB system is my baby, but ... For a start, most of our customers are highly resistant to moving from the old system to the windows version. Their reasons are basically as follows: Unmatched processing speed. A large payroll run with 20 thousand employees would take all night in the windows system. The old system pumps it out in a few hours. Stability. COBOL just runs. Printing. COBOL prints using the printers built-in text fonts, which print really fast. Plus has anyone ever tried to set up a line impact printer in Windows? Did you enjoy it? Stability v2. Which would you prefer, a system developed over 30 years, starting small and gradually growing more complex. Or a GUI package based on the first system and migrated over 5 years? The second obviously being more dynamic, complex due to the GUI, and with 25 years less beta testing? Data ownership. COBOL data files are stored encrypted on your hard drive. Convincing someone that they should relinquish control to the SQL/network administrator is tough going. Piracy. It's much easier to illegally copy the COBOL system. The Potty 1
ThePotty1 wrote:
Which would you prefer...
It depends... right now I wouldn't choose a face lift, but it all depends on the customers needs. I don't know how COBOL would handle things like Web Page Integration, Web Services Integration, Plug-in Architecture, High level of abstraction implementations... These are just a few that automatically popped out of my head and most are key areas for you to sell a software to a modern company. If the software is to be held in-doors, then almost anything will do if it works, but more and more customers want their applications to deliver services directly to customers, want the IT Department to respond JIT to the commercial demands making the process mo agile not to act like a technological corn. Like I said more than once already on this thread, if the company already has its own COBOL application and is satisfied with it's absolutely correct to keep it while it keeps doing its job. What I question is the new implementations, basically what future will they have?, will they be able to stand side-by-side with the company's needs?, even if it can handle it, at what price? Cheers! Alex