Do You Know Cobol? If So, There Might Be a Job for You. (wsj.com)

Despite its advanced age, Cobol is still the most prevalent programming language in the financial-services industry world-wide. Software programmed in Cobol powers millions of banking transactions every day and underpins critical computer mainframes. WSJ: And Cobol isn't going away anytime soon. Banks and other companies have come to the uncomfortable realization that ripping out old mainframes is pricey and complicated. Transitioning to new systems is likely to take years, and besides, a lot of the older tech works just fine. The problem is that Cobol isn't popular with new programmers. So, with a generation of Cobol specialists retiring, there is a continuing hunt to find a new generation of programmers to service this technology. In Texas, Mr. Hinshaw's (an anecdote in the story) company, the Cobol Cowboys, a group of mostly older programmers, is training U.S. military veterans in the programming language. Accenture is coaching hundreds of Cobol programmers every year in India and the Philippines to work at banks. In Malaysia, one consultancy that provides engineers versed in Cobol for its clients, iTAc MSC Outsourcing, has adopted the slogan "Keeping the Dinosaurs Alive." A host of companies offer online courses in Cobol in places like South Africa, India and Bangladesh. Developing economies are key technology-outsourcing centers for banks. Further reading: Major Banks and Parts of Federal Gov't Still Rely On COBOL, Now Scrambling To Find IT 'Cowboys' To Keep Things Afloat.

Comments

Seriously?

[SCVonSteroids]

Sure I'll go ahead and learn what I need to to keep your stack afloat.
What's that? You don't want to pay me a reasonable wage? Well then! I guess we have a problem indeed. Scramble on, fine HR folks at "Major Banks and Parts of Federal Gov't"!

Re:Seriously?

[quarrel]

Exactly this.

COBOL isn't hard. Whatever, it's a language.

But if you want to take smart people away from their shiny modern languages and dev stacks, and ask them to put up with bureaucracy, then you need to pay them at least commensurate salaries to what they'd get elsewhere (if not MORE).

These are really stories about banks not wanting to pay talented devs to put up with their BS.

Re:Seriously?

[Anonymous Coward]

It's nonsense anyway, the idea that Cobol is the most prevalent language in financial services still is complete and utter drivel.

I've worked for a number of financial services organisations, including banks, and I've not come across any still using it. After the whole Y2K drama and the amount they had to spend on contractors they spent the following decade deprecating it, and it's nowhere to be seen in the vast majority of financial services organisations anymore.

If you really want to know what the "most prevalent programming language in the financial-services industry world-wide" is, then it's Java, followed by C# and C++. R, Python, and SAS are fairly common in analytics work, and other specialist areas like quantitative analysis use the above coupled with a whole bunch of more niche language like F# and Ocaml (e.g. Credit Suisse), or even home grown languages like Slang at Goldman Sachs.

But Cobol? Yeah no, where did Slashdot find this article? 1999?

Re:Seriously?

[Tablizer]

COBOL isn't hard. Whatever, it's a language.

The hard part is reading and following piles of legacy code, some of which may have been written in the "go to" days.

Re:Seriously?

[eth1]

But if you want to take smart people away from their shiny modern languages and dev stacks, and ask them to put up with bureaucracy, then you need to pay them at least commensurate salaries to what they'd get elsewhere (if not MORE).

These are really stories about banks not wanting to pay talented devs to put up with their BS.

No, they're not going to pay well. Why do think they're doing this (from TFS):

Accenture is coaching hundreds of Cobol programmers every year in India and the Philippines to work at banks.

Can't wait for all the banking systems to melt down a few years later

Re: Seriously?

[Anonymous Coward]

cobol may not be hard, but the IBM mainframe environment/ecosystem those cobol apps run in is not trivial.

Re: Seriously?

[datavirtue]

Just left fin tech. Boring, great place to start but get the fuck out. They are notoriously bad at implementing tech and typically undervalue it.

Re:Seriously?

[DarkOx]

No even that is not 'hard' tedious often but not hard. People thought it was going to be hard, until they actually tried around y2k and it turned out to be not hard just a lot of work.

The hard part if there is a hard part is supporting the stack around it. What people, especially people on Slashdot who wrote some Microfocus COBOL in Windows for a college course some time, about COBOL is it does not run in vacuum. Its not the COBOL program that is hard. Its the fact that COPYBOOK is referenced in 65 different programs. Its the 500 JCL job steps before and after with their sync sorts and COND statements. Its the FTP and character conversion steps; and stuff that is scarping CICS and CICS web interfaces around the COBOL you need to worry over.

All this stuff amounts to Rube Goldburg devices that happened to be constructed from very very reliable and consistently operating components. So it all works and humms along for decades but try and replace any part of it with something new and feel the pain of running a square peg into a round hole.

Re:Seriously?

[CaptainDork]

I programmed in COBOL. I liked it.

It was easy for me to understand.

What was damned near impossible was straightening out the spaghetti code already in place.

The way to understand an existing system is to fuck around with it and get inside the programmer's head.

Once done, I can anticipate what's coming.

When a system is a hybrid of decades of code by quacks and pros alike, it's a goddam maze.

Management doesn't take that as an excuse and I excused myself from the management.

While the wage was competitive, the stress wasn't worth it.

I'll do startup with COBOL, but there's no market for that.

Re: Seriously?

[datavirtue]

And it continues to hold back the technical progress of the banking and payments industry because people are too chicken shit or incapable of moving away from it. I just spent five years dealing with one fiasco and limitation after another brought on by fucking COBOL and mainframe applications. They completely suck and totally mismatch with the way computer systems have been designed and built since it went out of style. It fell out of favor for a reason, don't glorify it. It hangs around frankly because government regulation is used to stifle innovation in the space where it dominates.

Re: Seriously?

[cshark]

Yeah, but every sufficiently large organization, corporation, and government has things about it that are untenable. For example, I'm working on a scala microservices stack right now, and it's relatively new. But the developers that deployed the original iteration didn't really know the language or the platforms they're working on, so the project six months in is as bad or worse than the worst vb and java apps I've ever seen.

Fucking verbose case classes EVERYWHERE, and entire sections of architecture that simply don't need to exist. And yet, pretty much everybody's okay with it. It works, right? At least against the mocks?

I guess my point is that there's no avoiding it. There's no such thing as quality in code in a production environment, and as a professional developer, you just get used to that unfortunate reality.

Granted, some environments are better than others, and I'm sure that's true about the banking sector as well.

Re:Seriously?

[Wycliffe]

You're demanding that salary only 15 years out of college? Wow, just... wow. That's well above the norm even in Silicon Valley.

That's his point. If you want someone to learn a language that is old-fashion, tedious, has limited growth potential, and is full of bureaucracy then you need to pay above market rates. At most programming jobs you are paid marketing rates and continue to stay up to date with technology and therefore can get a new job when your current job ends. Many programmers are even willing to take below market rate jobs if the work is interesting and has learning potential. Taking a job as a COBOL programmer, you lose all the niceties of modern languages and you also put your career on hold for the duration of the job. They could improve their recruiting a little if they paid people while they learned COBOL but companies don't want to invest in people like that anymore. To improve their odds even more they could pay people while they learned AND give out five year contracts AND find people who only have 5 years till retirement so that people are willing send their careers down a black hole.

The other option might be to do something similar to what many open source projects do and let people spend 50% of their time pursuing personal projects. This still requires them to basically pay double what the market rate is (as they are only getting 50% of the work) but is probably the most workable solution.

Re:Seriously?

[Wycliffe]

There is nothing to maintain. Skills don't just rot away.

Yes they do. Ask any foreign language speaker. They have to constantly maintain their language or they start to forget it. I used to be an excellent at C++. I haven't used it in 10 years and my skills are definitely a lot more rusty. I've forgotten many of the shortcuts for debugging, etc... I've also forgotten most of the calculus and physics I've learned in college as well as no longer have the periodical table memorized. I once read that you need to read X (don't remember the number) books per year just to not go backwards. This is the reason that most professional certifications require continuous education in order to maintain your certificate and license.

I skipped COBOL class deliberately

[presidenteloco]

So as to never be roped into a job like that.

In my defense, back then, COBOL did not even have an ELSE statement.

It was just pretty dumb.
And all the stuff written in it was stultifyingly boring.

That was the best 1% mark I ever sacrificed.

Re:I skipped COBOL class deliberately

[Ol Olsoc]

It was just pretty dumb. And all the stuff written in it was stultifyingly boring.

Yes, all about money and stuff like that. Paralyzingly boring. Who cares about lousy old money?

Quiet! all these young guys need to think that there's no money in supporting legacy systems.

Stay away! You'll be paid less than minimum wage! COBOL is dead anyhow - this is just fake News!

Maybe not a good career move in the U.S.

[ItsJustAPseudonym]

Accenture is coaching hundreds of Cobol programmers every year in India and the Philippines to work at banks.

So, if you are in the U.S. and you know Cobol already, you might get a few years of employment out of it. However, such jobs will go overseas, too.

Re:Maybe not a good career move in the U.S.

[oh-dark-thirty]

I'm around 10 years from retiirement and would happily ride that wave into the sunset. My very first real job was coding COBOL on a Wang VS80 (later we upgraded to the VS100, woo), I'm sure it would all come back to me.

You can learn Cobol well enough to get a job

[rsilvergun]

in about 90 days. Buddy of mine did it back in the day. But without a college degree you won't make it through modern HR filters. Why hire a high school grad for $80k + 40/hr/week when you can import a dev for $60k + 72/hr/week?

It's the context of the job that matters

[macraig]

Simply knowing COBOL isn't the deciding factor. Could I stomach being employed in the banking industry and facilitating the awful shit they pull? No. So whether I know COBOL or not is irrelevant.

Re:It's the context of the job that matters

[Tablizer]

Could I stomach being employed in the banking industry and facilitating the awful [bleep] they pull?

I've worked at/for a lot co's, and jerkativity is NOT limited to just banking.

Do You Know Cobol? If So, There Might Be a Job for

[bob4u2c]

do you know cobol? IF so, there MIGHT be a job for you.

Yeah, sure let me get right on that. If, might; why not waste my time on vague promises?

Would you even be looking for a job?

[OrangeTide]

The way COBOL programs are structured I think you had to have been programming in the 1970's to really understand the idioms and work flow. That means you may have been on the job for 40+ years already, putting you pretty close to retirement age if you were one of the younger folks to pick up COBOL in the late 1970's.

We're going to hit a brick wall in about 5 years on this, and some businesses will have to learn an expensive lesson about the sunk cost fallacy.

Re: Would you even be looking for a job?

[cyber-vandal]

Don't worry. India will do the needful.

Re:Would you even be looking for a job?

[OrangeTide]

Maybe they'd retire and spend time with your grandkids

oops, that turned unexpectedly creepy. substitute the appropriate pronounce.

Re: Would you even be looking for a job?

[thomn8r]

and Michigan

For the love of god and all that is holy - is there any 3rd-world country they *won't* exploit?

Stupid question

[Nidi62]

Stupid question here, but if big businesses are having all of their older, experienced programmers retiring and none of their younger programmers have the skills, why aren't they paying to train people that already work for them? Seems like that would be a lot easier and cheaper, plus they have the added bonus of already knowing what your business does/needs and how it works.

Re:Stupid question

[goose-incarnated]

Stupid question here, but if big businesses are having all of their older, experienced programmers retiring and none of their younger programmers have the skills, why aren't they paying to train people that already work for them? Seems like that would be a lot easier and cheaper, plus they have the added bonus of already knowing what your business does/needs and how it works.

Why [ay to train when you can make vague promises to the under-employed programmers who then train themselves on their own dime. Hell, you won't even need to hire all of them, just the best 10%.

Re:Stupid question

[bluefoxlucid]

Better question: why aren't they rewriting this stuff?

This is technical debt, a particular type of risk that piles up over time unless mitigated by taking other risks. Technical debt occurs when you solve a problem with a less-than-optimal solution to avoid a cost--whether that be time, money, or risk. Time isn't a factor here; rather, it's expense (small) and risk (large).

Banks pay quite a lot for maintenance of these systems, and can afford redevelopment. It's not that they're loaded with money, but rather that redevelopment isn't much more expensive (and is possibly short-term cheaper) than maintenance. Because time isn't a factor, a slow approach expending little cost per time--stretch the schedule to accommodate the available budget per quarter--would allow for redevelopment at about any cost constraint; and an agile delivery method integrating the old system onto a new baseline and delivering new components over time would allow better testing, earlier (partial) deployment, and risk mitigation.

Instead, they add new components, adapt to new regulatory needs, and write bits in Java and C and whatever. They cobble components together, integrate with other systems, and somehow get their complex and expensive code base to talk to another system written in Python to provide online banking. They keep dragging the whole thing on while adding more glue code and more core functions.

Somebody says it's not broken; everybody sort of shuffles around and tries not to mention that it might break if you sneeze too hard, and that it might not be easy to put it back together. If it's expensive to maintain and carrying the risk of minimal professional knowledge available in the field, it's broken: it's a huge risk waiting to bring immense monetary, regulatory, and reputational damage to your organization, and you're paying excessively to keep it around instead of trying to replace it.

Re:Stupid question

[Comrade Ogilvy]

Better question: why aren't they rewriting this stuff?

Because the actual requirements are pretty complex and easily underestimated. If you underestimate the complexity of a core system, the replacement project will be very expensive and could easily fail regardless of how much you pay. What makes it worse is these services shops like Accenture love big messy projects with vague requirements because they can make bank on the endless late game change requests that are necessary for the system to be usable.

It is not actually rare for big companies like banks and insurance companies to blow $50-100 million on replacement projects that fail. Literally. But the cost are rolled into some generic multiyear infrastructure improvement project and the CIT is forced out. Bummer.

Re: Stupid question

[datavirtue]

Absolute bullshit. Some processors like TSYS have rewritten this shit several times and use Java. Mastercard has had outages of their COBOL mainframe stack several times in the last few years.

Re:Stupid question

[bluefoxlucid]

Absolutely true. You implement systems like this in an incremental manner, with parallel deployment so you can thoroughly test. Basically, you form the foundations first, then begin building components, and create adapters to connect your existing system to these new components where they replace parts of the old one; and you run this stuff side by side, duplicating all actions so you can compare results from both systems. Each time you've sufficiently demonstrated a subset of components, you replace production with the new stack.

It's not cheap, and it's not easy; it's something you do when the risk of maintaining legacy is getting too big.

Programs are connected sets of operations and projects to fulfill a common business need; each project is a finite, well-defined, planned, and temporary endeavor. No project should vary its scope unless some risk event makes the prior scope unusable; changes within scope are common and natural, and your project needs a change control board to determine if and how to make those changes.

Unscrupulous project management shops with little technical expertise will suck your business dry by proclaiming that "the customer is always right!" and doing whatever you ask. As a project manager, it is your job to discover what your client wants--not what they're asking for, but what they expect to achieve. If they want you to build something and it won't achieve their purposes, you push back. They can cut the contract or force things through their executive suites if they want, and it's your job to drive them that far if they're trying to make unnecessary and damaging scope changes that will harm their business and ultimately cause the project to fail by delivering something not appropriate or functional.

They call that "Agile"; that's not agile. Iterative and incremental delivery is agile: show each workable unit so the customer can test, analyze, and give feedback before you go basing the next piece on that. This increases customer interaction frequency and reduces risk by continuously validating that the project is developing as expected and actually fits the needs of the business and the product. Running around with no plan and no governance isn't agile; it's bullshit.

Of course I like to get shit done; a lot of people seem to just like money.

not again! they don't want COBOL they want CICS

[Anonymous Coward]

oh, not again ... they do not want COBOL programmers, they want programmers who know CICS transactions and DB2, VSAM, etc, who have enough experience to come in and fix production business logic ... I see this article every year or two and it's ... let's all say it together ... NOT COBOL PROGRAMMERS ANYONE WANTS ... if you know COBOL but don't know CICS, you will not get a job... and, hey, there is a huge glut of out of work CICS experts to pick from.

Re:Do You Know Cobol? If So, There Might Be a Job

[DeBaas]

I'll learn a language that has an IF MIGHT loop, looks awesome!

Re:Repost

[Archtech]

I remember in about 1991 people were talking about how Cobol was "dead" and it would soon go away. I checked and found that over 100 billion lines of Cobol code were used in vital business systems every day.

In about 1995 there was another wave of "Cobol is dead". I checked the same sources and now it was over 200 billion lines.

Reality is that which doesn't change just because we don't like it.

Re:Most prevalent? No.

[shadowknot]

It really isn't a stupid anecdote. Go to SHARE or GSE in Europe, you'll see representatives from the largest financial, retail and governmental industries who represent the bulk of transactional computing in the world. Practically every debit/credit/charge card swipe goes through a COBOL program, and these aren't "legacy" systems that are simply being maintained but systems in active development. I know personally of programs that have been written to facilitate new features like various NFC payment technologies recently. I will grant you that it's a largely invisible sector of the IT industry, if I wasn't in it I would probably still be ignorant to it too.

Re:First?

[slickwillie]

He would have been first if he didn't have to type all that stuff:

IDENTIFICATION DIVISION.
PROGRAM-ID. FIRST.
PROCEDURE DIVISION.
DISPLAY 'First'.
STOP RUN.

COBOL Has Advantages

[sycodon]

You can be a snobby all you want about your C and SQL databases, but one thing two combinations will never do is what COBOL does every night, weekly, etc.

That is process millions...I mean MILLIONS of records in a single night, producing bills, checks, statements, etc.

COBOL is optimized for record processing, not pretty pictures, drop down menus, HTML, etc.

COBOL has once focus:

1. Get the data in
2. Transform it
3. Get the data back out.

COBOL can slice and dice data in ways C and SQL can't even dream of.

You don't write Websites in COBOL. You do the serious work that involves billions of dollars of transactions. Reliably, repeatedly.

Re:COBOL Has Advantages

[jythie]

Yeah, I used to feel the same way about FORTRAN, then I discovered you could do the same tasks in Python with the right library, far more readable, and only marginally less efficient.

Re:COBOL Has Advantages

[sycodon]

Not the same way.

Read up on the Redefines features.

Slice and dice before the code so your code isn't cluttered with Mid, Left, Right, Strip, etc.

Re:COBOL Has Advantages

[Archtech]

That's the funniest thing I have read about software since the IT director who was quoted as saying, "We're going with XML because it's the fastest Internet protocol".

And that wasn't Dilbert - that was real life.

Re:COBOL Has Advantages

[slack_justyb]

But then again, so could almost any other decent general-purpose computer language.

Depends but honestly, not really. I've worked C++, Java, COBOL and RPGLE. Most modern languages are general purpose like you said, and as such have to have libraries and what not added to them to make them SQL/Database/sockets etc aware. COBOL and RPGLE are pretty much specifically written to work with files/tables/transformations. Of course, the trade off is that those two languages become horrible for things outside that task.

Good example. In RPGLE database tables are files (actually the file concept came way before the table concept but I digress). You treat then just like you would any other file. Want a struct that matches the layout of a file (database table) you just define it to be like that file.

dcl-ds SomeStruct likerec( SomeRec : *all ) inz;

That's it. When you update the layout of the table, a quick recompile of the program updates the program too with no code change. You don't have to add getters, you don't have to add setters, none of that stuff that would be needed in Java or C++. If you want to store something from the database in that struct its

read SomeStruct SomeRec;

Change some values and then to update that changes back to the database

SomeStruct.SomeField = 'New Value';
update SomeStruct SomeRec;

COBOL is pretty much the same way except the op-codes are a bit more verbose as you indicated. Again, I'm not saying RPGLE or COBOL are better than C++ or Java or what have you. What I am saying is that they are languages that were developed for a very specific purpose and as such they are incredibly honed into doing that purpose quickly.

COBOL can slice and dice data in ways C and SQL can't even dream of.

I think that's a bit overselling it. Even the best COBOL can be emulated in C++, the catch is that somethings in COBOL are made a lot more complicated in C++. One thing is that COBOL has built-in understanding of how to build reports that will be printed. That's because COBOL was made to specifically address that kind of stuff so it's no wonder that in COBOL you can instruct a report to be printed with a single line of code. You can do roughly the same in C++ or Java but you're pulling in a ton of libraries to get that done.

Again, the folks who have used RPGLE and COBOL all their life, they'll swear by it. And I get it. For things like taking in massive amounts of records and doing the exact same operation on upteen billion records, RPGLE and COBOL cannot be beat because they were written to do exactly that. However, want to do some cool website UI? Yeah, RPGLE and COBOL are horrible choices to do that in. Want to do some sort of RESTful API? .NET/Java/Shit probably an abacus are all going to be way better choices than RPGLE or COBOL. The two are very, very specific languages in what they will and won't do, and processing billions upon billions of records like Charlie Sheen processes lines of cocaine, is exactly what these languages have had the last four to five decades to refine. You'll be incredibly hard pressed to find compiled output that matches their speed, that used a HLL outside of them.

Re:COBOL Has Advantages

[slack_justyb]

It's even got a built-in cycle, you don't have to tell it to READ a file, that's what it'll do when you give it a file name

Indeed the cycle is still there for OPM, but if you want ILE you have to ditch the cycle. OPM biggest use is exactly what you said, if you want to batch process a massive load of records. Where I'm at there's still some programs that use cycle because we load up data sent in from all the branches, doesn't matter if the file is 1,000 records or 100,000,000 records the batch for each branch is so quick the timing is considered to trivial.

Now, getting it to process things interactively, like a terminal screen

That gets more into where you'd used ILE to break things up into pieces. Granted, there hasn't been any motion to move away from DDS for TN5250, but with PCML and node.js now integrated into the stack, you can code a service program to build JSON and then send that to the IFS and have the UI done up by node.js programmers. Or if JS isn't your thing, there's Zend server that can speak to COBOL or RPG ILE via PCML, again though, you really want to be outside the cycle for any of that to be less than nightmarish.

But biggest thing is that you have a choice in which mode you want to run in, cycle is still king for a ton of ETL. But ILE makes more sense for larger, more complex projects. But it's still good that we have a choice.

Re:Do You Know Cobol? If So, There Might Be a Job

[Tablizer]

Trump would love COBOL; it's usually in all capitals and makes small things sound important, as if you are God commanding an army of millions who don't question orders.

Staying power

[Tablizer]

why aren't they rewriting this stuff?

Into what? COBOL has lasted 50+ years. How do you know Java or C# or Python will last that long (in viable numbers)? COBOL is kind of like Latin: it's stable because it's a dead language. Scientific taxonomies use Latin because it won't change on them.

COBOL also has a lot of built-in idioms for business data processing. Java etc. would have to use libraries to get similar, and those libraries may fall out of maintenance even if Java itself lasts.

In the Year 2000......

[commodore64_love]

Cobol programmers will be in high demand, in order to stop the Millenium Y2K bug

In the year 2018... the problem is still not fixed.

It's not about COBOL, it's about the ecosystem

[crgrace]

When people are saying they need people to fill "COBOL jobs" they aren't actually looking for COBOL programmers. There are looking for people who are willing to jump into excruciatingly painful dead-end jobs dealing with obsolete technology and working just to keep something afloat.

I had an internship with a Fortune 500 company (not a tech company) working on COBOL software in the late 1990s. The COBOL part was easy. It is a pretty simple (but verbose) language and doesn't take long to learn if you've seen FORTRAN, Ada, or BASIC. What *was* really hard was learning how the reporting and monitoring systems worked (we were basically gathering data from food production machines, reporting and archiving it).

Basically, everything in this division was run on old IBM mainframes (actually new mainframes/minicomputers emulating old operating systems... MVS and AS/400 or something). You didn't have a command line where you did your compile and link stuff... oh no, you had to submit jobs in a very finicky format using the mainframe's JCL (job control language). It was heavily customized for no good reason (that I could tell) so only a few of the really acidic and unpleasant old-timers could help you get your stuff going. You couldn't look this stuff up on your own because it was basically macros built upon macros from I'm guessing the early 1970s.

Anyway, this internship was soul destroying. Like the worst job I ever had. I worked my ass off and barely accomplished anything because the simplest thing was so hard and no one knew what the hell was going on. Every so often a "consultant" from HQ (we were a remote site in a different state from the headquarters) would come, install something, and then he (always a he) would leave while everything broke. Even though my internship was to develop a specific piece of new functionality, I spent most of my time figuring out what was going wrong and patching it.

So technically, I have COBOL experience now, but really I have a bit of experience bashing my head against a custom one-of-a-kind wall, and that experience isn't transferable.

To add insult to injury, it wasn't even a high-paying internship. The only good thing about this company was the culture was everyone was out the door at 4PM (hours were strictly 8AM to 4PM). Once I stayed to 6:30PM to fix a production server that was mangled by a messed up JCL card. (Oh god, the JCL cards. Of course they weren't punch cards because this was the 1990s, but you had to format the commands AS IF THEY WERE FREAKING PUNCH CARDS I guess because they were reusing old punch card parsing code. So, if you put a JCL mnemonic in the wrong column, the job failed. I wish I were making this up, I really do, but I'm not.) Anyway, I stayed till 6:30PM one night and the plant manager was so excited with my "can-do" attitude that he gave me a "golden nickel" which was one free lunch at the plant cafeteria. Yes, this was six months of my sorry life.

Re:Gee...

[angel'o'sphere]

I haven't seen anyone offer a training, boot camp or workshop in COBOL.
Because you did not look for it.

Google: cobol workshop

About 832,000 results (0.35 seconds)