Dave McGuire via vcf-midatlantic writes:
On 05/17/2017 07:33 PM, william degnan via vcf-midatlantic wrote: > ..I used cobol when I worked at dupont tso/JCL (Damn autocorrect) > > Cobol is obsolete though. My professional opinion
Your bank statement would disagree with you.
Cobol is *out of fashion*. Obsolete doesn't mean quite the same thing.
I still have customers actively developing their application with COBOL. With extensions in the compiler, they make extensive use of VMS RMS ISAM files. I stil can't make head-or-tails of those damn PIC statements.
If it's not technically obsolete, would you still say it probably /shouldn't/ be used? On Thu, May 18, 2017 at 5:55 AM, Brian Schenkenberger via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Dave McGuire via vcf-midatlantic writes:
On 05/17/2017 07:33 PM, william degnan via vcf-midatlantic wrote: > ..I used cobol when I worked at dupont tso/JCL (Damn autocorrect) > > Cobol is obsolete though. My professional opinion
Your bank statement would disagree with you.
Cobol is *out of fashion*. Obsolete doesn't mean quite the same thing.
I still have customers actively developing their application with COBOL. With extensions in the compiler, they make extensive use of VMS RMS ISAM files. I stil can't make head-or-tails of those damn PIC statements.
I'm not sure I'd even say that. While COBOL generally makes me want to vomit, and that's a common position, that's not the point. Organizations are using it for a reason: It's the right tool for their job, based on whatever criteria they've set forth. I really don't think it's up to any of us to assert that they're wrong. But apart from that, what would be the motivation for declaring its obsolescence? I assume the big deal is age. So, what's the cutoff age for modern vs. "obsolete", when it comes to a language? Note that I'm not talking about implementations of the language, but the language itself, as the COBOL compilers in common use today are current, modern, maintained products. C++ is 35 years old, C is 45, Java is about 20 I think. All have seen recent standardization activity, and all have seen recent development in implementations. Just like COBOL. I don't think there's much that's necessarily "new" or "old" about a language for representing and expressing data structures and algorithms, in cases where the language specification has continued to evolve. Yes, newer techniques (object-oriented programming) and newer habits (long identifier names, use of lowercase characters, column independence) come into being, but these languages continue to evolve to take advantage of them. Modern COBOL implements those newer things, specifically, along with many others. Now, ALGOL, on the other hand IS obsolete by any reasonable definition. There has been no standards activities in nearly fifty years, no evolution of compiler technology, no incorporation of newer ideas, and zero (or near-zero) general use. That's what I'd call "obsolete". (sadly, because I actually like ALGOL!) -Dave On 05/22/2017 10:19 AM, Drew Notarnicola via vcf-midatlantic wrote:
If it's not technically obsolete, would you still say it probably /shouldn't/ be used?
On Thu, May 18, 2017 at 5:55 AM, Brian Schenkenberger via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Dave McGuire via vcf-midatlantic writes:
On 05/17/2017 07:33 PM, william degnan via vcf-midatlantic wrote: > ..I used cobol when I worked at dupont tso/JCL (Damn autocorrect) > > Cobol is obsolete though. My professional opinion
Your bank statement would disagree with you.
Cobol is *out of fashion*. Obsolete doesn't mean quite the same thing.
I still have customers actively developing their application with COBOL. With extensions in the compiler, they make extensive use of VMS RMS ISAM files. I stil can't make head-or-tails of those damn PIC statements.
-- Dave McGuire, AK4HZ New Kensington, PA
I have since learned more about how Cobol is used today on IBM mainframes. Cobol is still used as a backbone data processing language at lot more than I knew of. There is a huge amount of data going through Cobol I/O processing. When I think Cobol I ask, isn't there something a column-less data processing platform like Hadoop cannot do equally as well? I guess that'd all be off topic, but it may simply be that it'd be too much trouble to replace something that works with something that *might*. Rather than say it's obsolete I change my characterization of Cobol to "nothing better enough" has come along to warrant replacement of the Cobol already installed. It's not obsolete as long as it's too much trouble to maintain. There is still work for Cobol. People are probably initiating fewer *new* Cobol projects than say Python, to do more or less the same thing. Or Big Data Hadoop. Those people probably find Cobol an obsolete solution. Bill On Mon, May 22, 2017 at 10:19 AM, Drew Notarnicola via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
If it's not technically obsolete, would you still say it probably /shouldn't/ be used?
On Thu, May 18, 2017 at 5:55 AM, Brian Schenkenberger via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Dave McGuire via vcf-midatlantic writes:
On 05/17/2017 07:33 PM, william degnan via vcf-midatlantic wrote: > ..I used cobol when I worked at dupont tso/JCL (Damn autocorrect) > > Cobol is obsolete though. My professional opinion
Your bank statement would disagree with you.
Cobol is *out of fashion*. Obsolete doesn't mean quite the same thing.
I still have customers actively developing their application with COBOL. With extensions in the compiler, they make extensive use of VMS RMS ISAM files. I stil can't make head-or-tails of those damn PIC statements.
It's not obsolete as long as it's *not* too much trouble to maintain. On Mon, May 22, 2017 at 10:54 AM, william degnan <billdegnan@gmail.com> wrote:
I have since learned more about how Cobol is used today on IBM mainframes. Cobol is still used as a backbone data processing language at lot more than I knew of. There is a huge amount of data going through Cobol I/O processing. When I think Cobol I ask, isn't there something a column-less data processing platform like Hadoop cannot do equally as well? I guess that'd all be off topic, but it may simply be that it'd be too much trouble to replace something that works with something that *might*. Rather than say it's obsolete I change my characterization of Cobol to "nothing better enough" has come along to warrant replacement of the Cobol already installed. It's not obsolete as long as it's too much trouble to maintain. There is still work for Cobol. People are probably initiating fewer *new* Cobol projects than say Python, to do more or less the same thing. Or Big Data Hadoop. Those people probably find Cobol an obsolete solution.
Bill
On Mon, May 22, 2017 at 10:19 AM, Drew Notarnicola via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
If it's not technically obsolete, would you still say it probably /shouldn't/ be used?
On Thu, May 18, 2017 at 5:55 AM, Brian Schenkenberger via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Dave McGuire via vcf-midatlantic writes:
On 05/17/2017 07:33 PM, william degnan via vcf-midatlantic wrote: > ..I used cobol when I worked at dupont tso/JCL (Damn autocorrect) > > Cobol is obsolete though. My professional opinion
Your bank statement would disagree with you.
Cobol is *out of fashion*. Obsolete doesn't mean quite the same thing.
I still have customers actively developing their application with COBOL. With extensions in the compiler, they make extensive use of VMS RMS ISAM files. I stil can't make head-or-tails of those damn PIC statements.
At some point, enough COBOL systems that support business functionality will migrate to newer solutions that do not use COBOL, and so the technology will start to obsolesce. That said, I predict it will be decades before the tipping point is reached. Folks like myself have no doubt slowed the rate by spending part of their IT careers integrating new technologies with COBOL systems, thereby minimizing the need to look elsewhere for business functionality. Though I loathe the language (can we be any *MORE* verbose!), one has to appreciate its ubiquity in business. To the trade rags that claim finding COBOL devs is getting tougher, ignore. I'm a C developer, and I picked up COBOL in a few days. Coupled with an experienced dev to help me navigate the build and test environment and understand the nuances of ENDEAVOR and SPF screens, (if I am remembering the naming right), I was off and running. And, only newbie devs get all defensive about programming languages. Those of us who are charged with moving business forward don't really care about the specific language in use. As long as their is some good rationale for the language choice, we fire up an editor and make things happen. Offshore firms also can provide lots of experienced COBOL dev at a reasonable price. Thus, if an when COBOL dies, it won't be for a lack of devs. I know OO COBOL was derided a bit today, and I am not sure I will defend it, but we seriously considered using it in 2006 to help with parsing and reading XML on the IBM zOS platform. I and the senior dev (a spitfire of a woman if I ever met one) decided that we could do all we needed in regular COBOL and getting all the mainframe devs to learn Enterprise COBOL wold be a lot of effort for little benefit (so, derision aside, I'd have used it, with no regrets) :-) I would go so far as to say that all good devs need to spend a bit of time supporting a business in a language like COBOL (I am sure there are other non COBOL options as well). I think it humbles a person to note that outside of the techie folks who spend hours on forums debating the merits of language constructs and such, there are other, far more important, considerations. Jim
To the trade rags that claim finding COBOL devs is getting tougher, ignore. I'm a C developer, and I picked up COBOL in a few days.
Big corporations are going to have HR policies about only hiring people with many years of experience in the necessary language, not those who "can pick it up". That's what they mean when they say there are not enough qualified candidates. I'm not taking sides :) just pointing out corporate reality. ________________________________ Evan Koblentz, director Vintage Computer Federation a 501(c)(3) educational non-profit evan@vcfed.org (646) 546-9999 www.vcfed.org facebook.com/vcfederation twitter.com/vcfederation instagram.com/vcfederation
On 5/22/2017 12:33 PM, Evan Koblentz via vcf-midatlantic wrote:
To the trade rags that claim finding COBOL devs is getting tougher, ignore. I'm a C developer, and I picked up COBOL in a few days.
Big corporations are going to have HR policies about only hiring people with many years of experience in the necessary language, not those who "can pick it up". Technically, it's not a policy. HR will look at anyone who matches the criteria specified by the hiring manager, and so they will reject only if the hiring manager specifies "X" years of COBOL. But, as a hiring manager, I can tell you I might do that if I need a lead on-shore resource, but if I am looking to replace a retiring COBOL dev, I will simply specify "COBOL experience" preferred, and if they don't have it, but they know C or Java and are OK with learning COBOL, I will hire them.
Or, I will pull someone from TCS or NTT or another off-shore firm. Jim
On Mon, May 22, 2017 at 10:33 AM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Big corporations are going to have HR policies about only hiring people with many years of experience in the necessary language, not those who "can pick it up".
That's what they mean when they say there are not enough qualified candidates.
I'm not taking sides :) just pointing out corporate reality.
Part of the problem may be that if you don't already have strong COBOL programmers, how can you tell if someone has the necessary COBOL skills? Who asks the hard interview questions?
On Mon, May 22, 2017 at 3:03 PM, Joseph S. Barrera III via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
On Mon, May 22, 2017 at 10:33 AM, Evan Koblentz via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Big corporations are going to have HR policies about only hiring people with many years of experience in the necessary language, not those who "can pick it up".
That's what they mean when they say there are not enough qualified candidates.
I'm not taking sides :) just pointing out corporate reality.
Part of the problem may be that if you don't already have strong COBOL programmers, how can you tell if someone has the necessary COBOL skills? Who asks the hard interview questions?
Q1. In a re4definitions clause, can you have "value clauses"? Q2. What is the syntax for an "88" level? Q3. What is the difference between a "Comp" field and a "Comp-3" field? stuff like that. b
Several year ago, my wife was brought into an Big Insurance Company (though I can't remember who now...Liberty Mutual maybe). Their bench of programmers who had been with the company for decades were getting ready for retirement. They were looking to bring in young folks, to train and keep on for the next several decades. This sounded like a fanstatic idea to idea to me -- alas she was not interested (and for some reason wouldn't refer me to her rectuiter ;) ) Point is, every place is different. --Jason On 05/22/2017 10:33 AM, Evan Koblentz via vcf-midatlantic wrote:
To the trade rags that claim finding COBOL devs is getting tougher, ignore. I'm a C developer, and I picked up COBOL in a few days.
Big corporations are going to have HR policies about only hiring people with many years of experience in the necessary language, not those who "can pick it up".
That's what they mean when they say there are not enough qualified candidates.
I'm not taking sides :) just pointing out corporate reality.
________________________________ Evan Koblentz, director Vintage Computer Federation a 501(c)(3) educational non-profit
evan@vcfed.org (646) 546-9999
www.vcfed.org facebook.com/vcfederation twitter.com/vcfederation instagram.com/vcfederation
My last exposure to COBOL involved its use as a generated language, in a "4GL" called LINC that came out of Burroughs: https://en.wikipedia.org/wiki/LINC_4GL LINC was a (dreadful) front-end language that generated COBOL and database code, which were then compiled into executable systems. When a system written in LINC was being ported from a Burroughs mainframe to a Sequent UNIX system, and the database changing from EBCDIC heirarchical DMSII to ASCII (different collating sequence) relational Oracle, one of the things I did was to write a C program that rewrote the COBOL between systems to properly transmogrify the data and functionality. Blech. Just to point out that things like COBOL show up in strange places, often causing them to far outlive their natural lifespan. On Mon, 22 May 2017 10:54:10 -0400 william degnan via vcf-midatlantic <vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
I have since learned more about how Cobol is used today on IBM mainframes. Cobol is still used as a backbone data processing language at lot more than I knew of. There is a huge amount of data going through Cobol I/O processing. When I think Cobol I ask, isn't there something a column-less data processing platform like Hadoop cannot do equally as well? I guess that'd all be off topic, but it may simply be that it'd be too much trouble to replace something that works with something that *might*. Rather than say it's obsolete I change my characterization of Cobol to "nothing better enough" has come along to warrant replacement of the Cobol already installed. It's not obsolete as long as it's too much trouble to maintain. There is still work for Cobol. People are probably initiating fewer *new* Cobol projects than say Python, to do more or less the same thing. Or Big Data Hadoop. Those people probably find Cobol an obsolete solution.
Bill
On Mon, May 22, 2017 at 10:19 AM, Drew Notarnicola via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
If it's not technically obsolete, would you still say it probably /shouldn't/ be used?
On Thu, May 18, 2017 at 5:55 AM, Brian Schenkenberger via vcf-midatlantic < vcf-midatlantic@lists.vintagecomputerfederation.org> wrote:
Dave McGuire via vcf-midatlantic writes:
On 05/17/2017 07:33 PM, william degnan via vcf-midatlantic wrote: > ..I used cobol when I worked at dupont tso/JCL (Damn autocorrect) > > Cobol is obsolete though. My professional opinion
Your bank statement would disagree with you.
Cobol is *out of fashion*. Obsolete doesn't mean quite the same thing.
I still have customers actively developing their application with COBOL. With extensions in the compiler, they make extensive use of VMS RMS ISAM files. I stil can't make head-or-tails of those damn PIC statements.
participants (9)
-
Dave McGuire -
Drew Notarnicola -
Evan Koblentz -
Garrett Nievin -
Jason Howe -
Joseph S. Barrera III -
RETRO Innovations -
VAXman＠tmesis.org -
william degnan