Posted in
(The uncertain future of CICS part 1)
The other day I was thinking about the future of CICS and what programming languages and technology we could be using in a few years time. Part of why I was musing about this was because of the age old problem of COBOL.
For the reader to understand this article, I have to explain where I started my IT career. Back in the eighties I started work as an operator and then a strictly batch COBOL programmer on an ICL machine. One day my boss decided to punish me for my rebellious attitude and bad programming techniques. The rebellion was real. The techniques in question included using a parameterized version of a batch program to generate reports instead of rewriting the same input/sort/report logic in each program.
The punishment was to banish me to the IBM side of the IT shop where I was suppose to languish and live a miserable meaningless life until retirement. This was a big ICL shop and the workload processed on the IBM box was about 1% of the total processing. The hallways were running waist deep with ICL bigots and so we IBM folk just kept to ourselves.
It is here where I was introduced to CICS. In these relative obscure surroundings I learned about BMS, VSAM and DL1. When viewed in isolation - developing CICS programs seemed simple enough. What made it difficult was adhering to the mindless standards set by our project leader.
Her name was Matilda. Matilda was a middle-aged spinster with a determined expression on her face. She lived with her dogs in a small apartment - somewhere. The fact that she was a spinster would probably be irrelevant to just about any conversation on computers. Except for me to describe her personality would take too long so suffice to say Matilda was set in her ways and a little narrow minded.
One day I arrived at her desk with the news that my first major CICS program has been completed. She responded sternly with a request to see the listing. I arrived at her desk with the listing and a slightly diminished enthusiasm. I was starting to get the feeling that something is about to go wrong. I was right. She flicked through the listing with an ever increasing frustrated look on her face. It climaxed in her casting the listing into her trash bin. My eyes followed the listing and then I heard the ominous words "This is not according to our standards. Here is a listing of how you should program follow it closely. I expect every aspect of the program including variable and section names to be the same. I expect the logic flow to be the same except of cause where the program needs to be different".
What followed can only be explained as months of hard labor where the labor in question consisted of coding. Well - calling it coding is hardly apt. It consisted of a robotic copying of my old programs into new programs and changing what needed to be different in order for the new program to fulfill some wish of my project leader.
It started small but quickly grew into a full blown resentment for computers. I hated my job and almost left the field. I was not surrounded by beings that liked computers. I was surrounded by people that liked money. They wanted to do enough to get by and get paid and go home to their families.
There was no scientific thrill in developing something cool. Hey! this was COBOL and CICS and this was the "real" world of serious business. The cool stuff belonged to the universities and colleges where the "immature" academics played with funky languages like LISP and Ada to do simulations and other meaningless stuff.
I started to develop a new way of programming COBOL and after I ended up being a project leader, I tried to teach people how to write a light version of the language that employed reusability when applicable but most of all kept program sizes small and understandable. The Nassi-Schneiderman crowd ridiculed me for being a heretic. But I found some solace in the fact that I got the respect from the Assembler programmers for developing well performing code.
Fast-forward ten years and about three thousand COBOL programs. I grew increasingly frustrated with the repetitive nature of the COBOL program development process and the inflexibility of the language. The verboseness of the verbs started to eat away at me but I still loved programming. I heard of other languages but because I did not want to stop working on CICS, I stuck with COBOL.
When IBM made C++ available on CICS I started to develop C++. It also happened as the pressure from the non-mainframers pushed for a modern approach to application development. They use to tell tales of the Promised Land where everything was an object and reusability would propel us into a higher form of existence. I was interested but chose to stay with CICS and see what could be done in C++ on the mainframe.
Thankfully client-server just about imploded due to weak networks and unstable operating systems like Windows. The gluttonous design of some object orientated systems just about nuked the weak processors of the nineties. There was a bit of reprieve for the mainframe and the COBOL crowd gloated. Year 2000 rolled around and everybody was distracted by the hype of the moment.
But then processors got stronger and we found ourselves in the internet age. I started work on a CICS integration product and my C++ knowledge increased dramatically. I missed the string handling of COBOL but the light, non-verbose, reusable nature of the C++ language charmed me like a seductress that I had to return to time and again. I fell in love with object orientation.
Some time after that I tried to read the object orientated guide for COBOL. I found that I kept on putting it down in disgust. It was not the mindless way that they shoehorned the OO aspects into what is still essentially a reporting language. It was the verboseness that I could not handle anymore! I could not make the language adapt to my world. There was no overloading of operators or creation of classes that allowed me to mold my own reality. Instead I still had to go offer on the altar of verbosity whenever I wanted a good crop. It was like an old familiar coat that wore out so slowly that I did not notice it and when I finally paid attention, I slipped the COBOL coat of my shoulders and left it behind. I walked away from COBOL in my heart.
I also learned scripting languages. The traditional conservative mainframe segment of my personality kicked against the non-compiled nature of the language and basically the description of "scripting" made it felt like it was not a "serious" language. Then I remembered the serious mindless months of repeating the same COBOL program over and over in Matilda's salt mill and I shrugged my shoulders. The COBOL coat was not there to weigh me down anymore. I was free and could adopt the scripting languages for what they were, wonderful productive tools when used in the right context.
So this brings me to the nature of development in CICS and a very serious question:
Is COBOL killing CICS?
I believe many developers have walked away from CICS development because they associated it with COBOL. The adoption of new programming languages has been slow in CICS. Apart from a few splinter groups that do some C++ and Java – the bulk of development seems to be in COBOL.
Most of us still use oil based products to drive our motor vehicles. It works and up to a few years ago was relatively cheap. The industry around it is well developed with a gas station on every corner. But we all know, we have to get away from using these resources. Evidence seems convincing that burning fossil fuels is detrimental to our environment. Yet we still do it because - well it will be uncomfortable to switch to something else. We are in a comfortable groove with fossil fuels and sometimes it is easier to keep running in a groove than to venture into something new.
I realize the oil analogy breaks down on some levels so here is another one. Sometimes I think the COBOL crowd has dug themselves a cave in the land of CICS from where they defiantly rule. This rule prevents other people from moving into the land because the territory is associated with being old and antiquated.
In fact we might as well admit it, CICS is rarely associated with what is new and exciting. But why is that? In the next few blog entries I will start to investigate this.
Is the software old? No, IBM frequently updates it and brings a steady stream of new technology to the product. Is it the environment it runs in? Yes - I will admit the fact that CICS is still mostly associated with the mainframe and green screens hurts it. But WebSphere also runs on the mainframe...and it is not associated with being old.
I believe COBOL has created an "Irresistible force paradox" in CICS. (http://en.wikipedia.org/wiki/Irresistible_force_paradox). The very same thing that has been the bread-and-butter of the mainframe for so long and has helped IBM build their mainframe empire, is the thing that threatens to kill it but more specifically in this case, CICS. The monstrous monolithic mass that is the 500 billion lines (http://www.expresscomputeronline.com/20040906/opinion03.shtml)
of COBOL code that companies still maintain has become a dingy little secret that is kept in the basement of many a fortune 500 company. That missing code, the retiring programmer community has become the "Unmovable Object".
On the other hand there is the "Unstoppable Force". Modern technology moves fast. It is partly a product of a new type of computer culture. Today's darling programming language gets labeled with being "legacy" tomorrow.
Today's IT professional knows many technologies but most importantly enjoy working with computers and want to learn new interesting "stuff". The internet with its Web 2.0 technologies are moving fast and creating complex applications at a mind numbing pace.
"But we created a web program in COBOL and it runs on CICS!". You say. Yeah but the guy in the cubicle next to you created a new web application comprising of several class libraries using his favorite scripting language, deployed it then created a blog entry and proceeded to read up on the latest technology trends before lunch while you were compiling for the seventh time...
Is this a young vs old problem? Maybe. I am 40 years old and I still love computers and new technology, and I love CICS! I am probably antiquated according to some young code slinging person, but in my heart I am as young as ever and still seeking to enjoy working with computers. Too many COBOL people blame the fact that they did not learn something else on their age. But how do companies deal with the unmovable object?
Companies actively develop themselves out of trouble. They have given up on converting or migrating COBOL code or COBOL people to anything else. They replace the functionality with newer systems, in modern programming languages developed by enthusiastic people that enjoy working with computers. In fact I dare to say that the users of modern programming languages and technologies has a much firmer grasp on information management and computer science theory than the typical COBOL programmer.
So in concluding this first chapter of the "The uncertain future of CICS" I make the statement that there is something rotten and this time it is not in the land of Denmark, but in the land of CICS. And I believe that stench is the smell of death originating from the province of COBOL!
- Corneel's blog
- Login or register to post comments
Wed, 2008-04-09 07:18
#2
Earl - it is not that I
Earl - it is not that I don't like COBOL - I have just found better ways to do the same work. COBOL served its purpose when the planet needed it. At this stage there are better vehicles to take us into the future.
Wed, 2008-04-09 10:17
#3
Your right COBOL served its
Your right COBOL served its purpose and its time for it to retire. Unfortunately, it will take many years to replace all the COBOL code that is out there. It will be interesting to see how the industry handles this issue when all the old time
Mainframe guys have retired. Could be, the COBOL Cowboys and Cowgirls will be called upon ($$$$) to saddle up for for 1 more ride to extract business logic buried in the code.
Mon, 2008-04-14 08:02
#4
Re: Is COBOL like Oil?
Hi Corneel,
I have posted a reply here: http://masterterminal.wordpress.com/2008/04/14/re-cobol-is-like-oil/
Thanks
Chris Hodgins
Mon, 2008-04-14 10:20
#5
Re: Is COBOL like Oil?
Hi Chris,
I think the problem we are facing is that the pool of eligible developers is much smaller when it comes to potential mainframe programmers and systems programmer. At this point only a selected few students have access to mainframe related classes and very few even know anything about the mainframe nor do they care. They have FREE access to programming languages(C/C++, PHP, PERL, Ruby etc.), enterprise class operating systems(Linux), Transaction processors(Apache), Databases (DB2, MySQL, PostgreSQL etc.). In most cases they even have access to the source code of these products and can really dig in if they want.
There is NO entry point into the mainframe.
Anybody can go home after work and write a piece of software to provide a service or to sell using PHP, MySQL and Apache. (That's what I did with the CICS Community Forums). I would have loved to do that on CICS but at what cost?
Where is the CICS Community Edition?.
There are a few people in the CICS community that really cares about the product and are willing to go out of there way to promote it and get the community involved it. Most people just shrug shoulders and ask "Why ?"
Maybe our average age has something to do with it? [url= http://www.cicsworld.com/node/157]49.5[/url]
Regards
Ian
(cross posted on The Master Terminal here)
Wed, 2008-04-16 10:00
#6
Is Cobol like Oil?
Interesting topic.....we have a lot of Cobol code here. Some generated by CA Gen (originally called IEF) along with some native Cobol applications. But, all of the communications front-end is written in mostly C/370 with some Assembler code for good measure. So, there could be a path for restless C programmers that want to try the mainframe.
Kevin
Wed, 2009-02-11 05:24
#7
COBOL isn't going away anytime soon.
1st off... the lack of adaptability of 'modern' languages is not because of a mindset, it is usually because of a business decision, that it is easier to find/retain CICS programmers conversant in COBOL, then to find CICS programmers conversant in COBOL, PLI, Assembler,REXX, JAVA and C. IBM did it's part by making JAVA, C and REXX available in CICS many years ago. But it costs a company money, time and productivity to get a team of programmers multi-lingual. Do you think companies should spend the money, time and productivity and future added expense because you were BORED.... that's a bit naive.
It is far easier/cheaper for a company to maintain 1 or 2 code language bases, than 5 or 6... The KISS philosophy applies.
Your disgruntlement with programming standards shows a lack of professionalism on your part. This is what the business people would call the 'cowboy' mentality... the attitude that a technicians convenience/amusement is somehow more valuable than what an error might cost a business, millions of dollars in downtime. In a large scale professional programming team environment, this would not be tolerated... Failure to adhere to standards is a total lack of respect of your fellow programmers time and effort and the business you might work for. People who have been operating in the mainframe environment generally understand the business implications, thereof, and respect this. Your failure to understand and respect the business implications, seems to indicated that Matilda protected your butt, TOO much. When an outage in the mainframe world can cost a business $1M/hour or more...the business units would not give a rat's ass, about firing some $70K/year programmer, who's oddball approach/attitude to programming made his peer spend an extra 2 hours debugging a system outage, that cost the business 7 figures a pop. They could always find a new programmer with the 'right' stuff. When Matilda was making you adopt to standards... she was protecting your butt from the business units...Don't you get it?
Also, by the way, CICS 3.2 fully supports Web 2.0... you can use Eclipse IDE to interface with CICS, too.
You also seem to lack awareness that Websphere can and does backend to CICS in many shops.
You also need to understand the history of computing before judging the long term prognosis of COBOL...
As you can clearly see... C has not become the 'COBOL killer' that people bragged about in the 90s... The same bragging that was said about PASCAL being a 'COBOL killer' in the late 70s/early 80s and about Fortran or PLI being the 'COBOL killer' in the 60s. While the popularity of COBOL may have plateau'd many, many years ago.. It's code base is still growing, to this day. The same can't be said about PASCAL and Fortran... As you yourself imply, LISP and ADA have seen better days, and C seems to be on the wane now, too... as JAVA is now the new 'darling' of the programming languages now, IMO(and yes, I am spending my own time and money learning JAVA, too).
The issue is maintainability and always has been. Do you envision any business application in Wintel/UNIX being around 20, 30 or 40 years hence... I don't. CICS was built as a long term system solution, not as a reusable plastic bag to be thrown away every 2 weeks. COBOL has it's self-documenting style(or as you put it standards/mind numbing repetitive nature), which means that the code is not being re-written because the next programmer inherited someone elses code that they couldn't understand or in a language that became passe(have you maintained anyones PASCAL programs from the 80s?...lately... I don't think so-- while maintaining a 20 year old COBOL program is not unheard of and would not be a major problem with a current COBOL programmer).
You also seem to lack understanding of the significance and importance of CICS in terms of parallel computing power... while parallel computing(let alone grid computing) skills remains a rare and elusive skill in the Wintel/UNIX world... CICS gives parallel(and grid) computing to many a programmer and their business...
You also fail to understand that what you might consider 'new' technology is generally old technology/approach re-engineered on a new platform...
SAN technology is similar in function to DFSMS from the 80s...
ILM(information life cycle management) is DFHSM from the 80s...
zen, VMware virtualization is similar in function to z/vm's predecessor from the 70s.
heterogenous grid computing is similar to NJE computing...circa 1970s...
Cooperative homogenous grid computing(in theory) is similar to sysplex computing from the 80s...
(FYI... HP doesn't foresee cooperative grid computing(cloud computing) in the near future for UNIX/Wintel... in an announcement earlier this year "Cloud computing not being appropriate for enterprise computing" I don't think Sun or MS have figured out that there is an issue, yet... and some of those in academia are only beginning to understand the complexity involved in enqueue, dequeue locking and two phase commit processing in a multi-machine environment)
Copybooks/PACBASE(aka... CASE computing) is similar to class libraries..
HTML pages is similar to ISPF panel dialogs...
Physical partitioning has been around the mainframe world from the early 80s...
Parallel sysplex computing equivalent is still at least about 2 decades away in Wintel, IMO.
You seem to fail to understand what IBM's long term plan for enterprise computing is ...CICS's future role in enterprise computing is not to disappear, or to be the dominant front end, like it has been in the past... but to serve as a back end transaction server... IBM envisions CICS connecting to Linux(or Solaris) images, running on IFL engines, on the same mainframe... using hipersocket(virtual switch) connections...via CICS Transaction Gateway.
Thu, 2009-02-12 05:30
#8
Re: COBOL isn't going away anytime soon.
Well I am not sure where to start but here goes:
If companies do not want to spend the money on retraining employees on new languages - does that not prove that COBOL is dragging CICS down with it?
The actual reason is that once somebody has coded in COBOL for a significant time it becomes difficult to impossible to retrain them. I know - after 15 years of coding in COBOL, I made the switch to OO and it took a full two years to start thinking different. That is if you WANT to change. Most older CICS people don't want to learn new languages because they either think they can make retirement on their current skillset or they are bigoted...
No I was not bored - I was looking for something better. Maybe I felt like Edsger Dijkstra when he remarked that "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense."
I also use to defend COBOL until the blood flowed - until I learned other languages. Before that I probably coded well in excess of 3000 COBOL programs. After that I performed software development on CICS in C++ and lamented the fact everyday that more CICS people were not willing to give it a try. (And also that IBM insist on charging for their C++ compiler). After that scripting languages taught me that there is even more productivity to be had if you are willing to let go of what you cling to with such determination.
Ever heard of the Gang of Four or GOF? Probably not. Do yourself a favor - read Design Patterns: Elements of Reusable Object-Oriented Software and pray tell me - HOW would you implement design patterns with COBOL?
That is what older mainframe professionals like you don't understand. COBOL has limitations that renders the code less prone for reusability. Oh yes we preach to people to implement layers in their COBOL code (Presentation, Business and Data layers) - but few older COBOL people do that. Most COBOL code I have seen in twenty years are long monolithic chunks of code.
Yes - good news was - I found that there is more to computers than COBOL.
Some of your other silly statements were:
"Do you envision any business application in Wintel/UNIX being around 20, 30 or 40 years" - yes and there is already much of that. Try to get out more - there are other platforms that can also provide a stable environment.
"CICS gives parallel(and grid) computing to many a programmer and their business" - Yes if your idea of grid computing is very shallow. Tell me - how many super computers do you know that runs COBOL? With what IBM charges for CICS mips - it is truly one of the most expensive execution environments in the world. That will always limit implementations of more complex systems on CICS.
"You also fail to understand that what you might consider 'new' technology is generally old technology/approach re-engineered on a new platform..." - Hmmm - I DO understand all that and I totally agree with that list you gave us. In fact - I also use to get on my soapbox and tell everybody that wanted to hear (and a few that didn't) that many mainframe ideas is being recreated on open systems. Guess what - nobody cares! I remember how evangelists use to punt the benefits of VTAM over TCP/IP...Uhhh nobody cared and today TCP/IP rules the roost.
"You seem to fail to understand what IBM's long term plan for enterprise computing is ...blah blah" -
No YOU don't seem to understand having efficient code on CICS is NOT part of IBM's game plan. It simply does not sell hardware. Check this article: http://www.cicsworld.com/node/147 - IBM is giving people money not to develop on CICS. If you truly believe all that about Linux that accesses CICS - you don't understand the game plan.
"Also, by the way, CICS 3.2 fully supports Web 2.0" - I have an AJAX application I would like to use against CICS. Can you tell me where I can find the JSON driver in CICS?
"COBOL has it's self-documenting style" - If you really believe that - you don't understand the purpose of documentation. I don't care what you are doing - I want to know WHY! I can see what the code is doing - what I want to know is - what are the business reasons for doing so?
"Matilda protected your butt, TOO much" - She never did - I eventually ended up training her on CICS.
"You also seem to lack awareness that Websphere can and does backend to CICS in many shops" - I implemented my first JSP WebSphere application with a backend CICS region in 2001. (It was WAS 3.5 and it was primitive!)
----
Ok so before we wrap it up - check out this link:
http://www.google.com/insights/search/#q=COBOL&cmpt=q
It shows the waning interest in COBOL. Also notice the following - most of the hits are from India ... its called outsourcing.
I don't know a single company here in Jacksonville FL that support new development in COBOL and with that CICS is being dragged into oblivion.
I could go on but this is simply not worth it. We get it that you were upset about article - but the personal attack was uncalled for and hence the defense...
Fri, 2009-02-13 01:57
#9
COBOL isn't going away anytime soon.
"Oh yes we preach to people to implement layers in their COBOL code (Presentation, Business and Data layers) - but few older COBOL people do that. Most COBOL code I have seen in twenty years are long monolithic chunks of code" "IBM is giving people money not to develop on CICS. If you truly believe all that about Linux that accesses CICS - you don't understand the game plan."
"I don't know a single company here in Jacksonville FL that support new development in COBOL and with that CICS is being dragged into oblivion."
You see the evidence, but still don't get it...... CICS Transaction Gateway was invented for a REASON... To add the GUI and other goodies you think are so preciously cool in Windows, UNIX, etc.. to CICS, already....... It has been around about 10 years now... What tools do you think aren't available to CICS via Transaction Gateway, that is missing.. Considering that gateway covers the WINDOWS, UNIX, LINUX and other worlds... probably not much.
AND WHERE exactly did I state that companies SHOULD pursue new developments in COBOL... my point is that IBM should not pursue, dumping COBOL from CICS. COBOL is what is keeping CICS alive, past it's time, IMO. You also seem mighty free on expressing your opinion on how other companies spend THEIR money, whether it be in training, development and productivity...TALK is cheap...
IBM envisons CICS's future as being the BACK END...transaction server, not the presentation layer, as the long term future for CICS. Why should IBM invest any money in any presentation level tools in CICS, when they can collect a license for TG and let others develop the GUIs without a cost to them? They do call CICS... TRANSACTION Server for a reason.. not data server, not application server... and have been for the last 3 levels(and releases)... about 8-9 years now. But NOOO... you seem to think IBM should add more support for another language... WHY? What back end server functions do you think should be added... the issue isn't that COBOL is killing CICS, but that you don't understand this back end server layer/presentation layer strategy that IBM has been using. This kind of strategy is not unique to IBM.
You still don't get it about standardization and why it is important to follow the corporate strategy, despite my explanation that these things cost companies money and the evidence you presented that shows YOU made a costly screw up("And also that IBM insist on charging for their C++ compiler")... WHO do you suppose is paying that C licensing cost, now? Who is supporting that C code now. Most Software is not free, hardware is not free, electricity is not free, most development is not free, maintenance isn't free, training isn't free..... Technical decisions have dollar consequences...
Someone has to pay for the software that is used... someone has to pay for the hardware that is used...
Where in the world did you ever get the idea that lowly programmmers should unilaterally have that kind of control over multi-million dollar IT budgets to add whatever cost they see fit? Where in the world did you get the idea that you can use whatever technology/method you please in a production environment for a business you don't own, and not have to address any long term support issues and costs? These are business machines, they are not your personal toys, you don't own them, and many of these machines have multi-billion businesses dependent on them..with possibly 10, 20 or 30,000(or more) employees behind it. THIS is part of a system programmers responsibility to THINK and REPORT about long term issues, especially when introducing new items and how it impacts your client/employer. Things such as disaster recovery, error recovery are part of a system programmers job to think through, too. This is what separates the professionals from the hacks who just happen to get paid for coding.
The companies are not paying system programmers so they can get their coding/technology fix... They are paying them to support the businesses systems...and to look out for the companies best interests...
You can have your opinions on what technology should/shouldn't be used... but IT budget managers, project leaders, other programmers, CIOs and others can have their own opinions, too... but ultimately, it is the person paying the bill that has to make the final decision and deal with any justification and prioritization. If you don't present the cost justification, on how things benefit the company, for your technological opinion... your opinion will be dismissed, justifiably, by those making the decisions and they won't be wrong for doing that.
"We get it that you were upset about article - but the personal attack was uncalled for and hence the defense... " Gee, where did you figure I was upset, and where did I get personal, you on the other hand have been more than willing to take personel shots, not only that you are willing to make assumptions to justify your attitude......... IMO you have acted unprofessionally...
you come out of your way to blast COBOL and IBM(the exact term is, you came out of your way..looking for a fight)... on a CICS message board, and now don't think people can't have their own counter opinion(gee who's being upset)... and state how they think IBM should handle CICS's future development.
Let's go over them one by one...
"The actual reason is that once somebody has coded in COBOL for a significant time it becomes difficult to impossible to retrain them"
BS... Have you ever been to the SHARE conference.. how about the Impact conference(or it's equivalent)...I have... There are plenty of people over 50 at these conferences.. In fact a majority of them are probably over 50(ie.. older than me), by my guesstimate, a few of attendees, I would suspect are in their 70s and 80s...I would be willing to bet that I've been to more conferences to learn, over the last 5 years than you have... I have attended and listened to IBM technical strategy speeches... I have attended several lectures by the CICS Hursley people...(among other IBM experts)...
and FYI... I have used over 8 programming languages during my career, including OO and scripting languages... and COBOL is not my primary language choice... I have also supported other platforms, other than mainframes, and I also do follow computing trends, including the Gartner reports, the IDC reports... and the financial reports.
"Ever heard of the Gang of Four or GOF? Probably not. Do yourself a favor - read Design Patterns: Elements of Reusable Object-Oriented Software and pray tell me - HOW would you implement design patterns with COBOL?"
Ever heard of PACBASE/COPYBOOKS, how about CASE(yes You have, since I already mention it)... reusable code is not something new and COBOL has had it for quite some time......
Here is the question to ask yourself... If you think the answer for CICS is OO and scripting languages... WHY isn't there a great demand for C/CICS programmers, JAVA/CICS programmers or REXX/CICS programmers...
The issue is not the choice of programming languages supported by CICS... but that you failed to understand that IBM strategy has been to encourage business customers to modernize their application/presentation layer for CICS(and specifically outside of CICS) to Linux for over 7 years now. Is this strategy working... you decided... IBM's server revenue market share was 19% in 2000... it is now 32%...and most analysis credit LINUX. SUN has given it's blessing to running SOLARIS on zseries... The Sine Nomine people(the guys who first created zLINUX) already have it available, last quarter. www.sinenomine.net
Mon, 2009-02-16 10:44
#10
COBOL isn't going away anytime soon.
The reason why there are no demand for C/CICS JAVA/CICS programmers is because companies don't develop those applications on CICS. The reasons why companies don't develop in those technologies are:
1. IBM charges too much for CICS MIPS to warrant development in OO languages.
2. The older mainframe generation like you have proven too hard headed, inflexible and opinionated to understand the benefit of OO languages over COBOL. (You have already proven this point abundantly in your previous rants)
You also have this attitude that I often get from old mainframers - you think the only important systems are developed on mainframes and that only mainframers are serious about business and standards.
I think the most comical comment of all is where you said that copybooks are similar to classes... That in a satirical sort of way says more than anything I can add.
The original point stands - COBOL is killing CICS in a similar way than OIL is damaging the climate. Now you can rant on but I am done wasting time on your comments.
Corneel, It sounds you don't like COBOL.