COBOL- still standing the test of time

The debate over COBOL’s continued relevance and indeed its future continues to persist in the developer community and IT world in general. But while every business has its language preferences, there is no denying that even though COBOL is 60 years old, it continues to play a vital role for enterprise business applications. COBOL still runs over 70% of the world’s business and more transactions are still processed daily by COBOL than there are Google searches made.

While many also debate the status of Java in relation to COBOL for business applications, COBOL remains the preferred choice for systems where application quality and operating cost remain important considerations, so often the case when addressing the ever-present issue of IT debt. When many businesses are facing mounting IT debt, the average cost per line of code for COBOL was projected to be £0.80 whereas the cost to address Java quality issues per line of code was £3.47, according to a recent IT study.

The benefits of COBOL, however, are not found in its exclusivity, but also in its ability to comfortably co-exist with other programming languages- such as Java – that are typically used to build new front-ends for new platforms and devices.

COBOL can function efficiently for vital business applications as a reliable language while also liaising with languages such as Java and C#, typically used in the construction of new interfaces; these languages combine forces in helping businesses deliver the services to support new requirements such as BYOD and other mobile initiatives through renewed, composite enterprise applications. While some in the industry may doubt COBOL’s relevance for today’s business applications – mainly due to its considerable age as a programming language – the fact that it has been vetted and proven over several decades actually stands in its favour: much of the required “new” functionality already exists, written in COBOL. It is merely a question of how it is made available to the user.

Add to this the flexibility of the language to be adapted for future needs, and its ability to liaise with other front-end  technologies, and COBOL remains a lower-risk option for businesses because of its prevalence over the past half a century, and not in spite of it. It is a myth that IT organizations must choose between one language and another – they can in fact work with whichever language(s) make most sense according to their business requirements. And ageless COBOL continues to meet those needs.


Why does COBOL remain the smart choice for application providers and development teams?

Portability is the key.

‘Choice’ is a defining characteristic of the IT industry. Whatever the question – there are multiple answers. Whatever the challenge – there are multiple options. This is especially true for enterprise application platforms.  Most enterprises sport disparate, heterogeneous platform environments.

Application vendors can have to support upwards of 40 platforms, with the appearance of new variants each year adding to the complexity.

IT organizations face internal pressures from tactical investment programs, a need to lower total cost of ownership (TCO), and a demand not to be locked into a single platform vendor. For most, the important measure is the TCO; both the initial investment charges and recurring annual hardware and software maintenance.  The pressure is on to maximize ongoing value, while removing cost and platform complexity.

Increased commoditization puts portability center stage

Increases in processor power and hardware commoditization present IT buyers with choices when it comes to platform selection: Windows, Linux, Unix, PC or Mac, Desktops or VMs, Mainframe or non-Mainframe, iSeries, Data Center or Cloud. Exploiting this choice lowers TCO.

The blurring of demarcation between platform choices now means that software vendors must make their applications available on a wider range of platforms. Customers will, of course, choose an application based on its functionality, but the decision will also consider the breadth of platforms supported, relative ownership costs, user requirements, skills profiles, supply-chain policy, etc.

Market dynamics of key vertical industries throw even more challenges into the mix. Telecoms service providers, for example, need to lower their cost base and leverage more ROI from their existing IT investment, as well as preserve the differentiation their systems give them. Delivering this cost-effectively, regardless of platform selection, is a major driving force. In financial services, competitive advantage is also deeply entrenched in application code, so it’s important to be able to re-use and harness this value.

Business dynamics of end-user requirements also have a direct impact on the application supplier as the application must work consistently and deliver a uniform process and user interface across the platforms their customers deploy on. This has a knock-on effect in terms of increased support and development costs, and slower development cycles as they get to grips with different tools to build systems on different platforms.

The priority for application providers and corporate development teams is to focus efforts on developing and enhancing their own products, rather than ensuring that they work on an idiosyncratic platform choice. Using different development paradigms to support different deployment options only deflects that focus.

Knowing that the end-user just wants correct business functionality deployed to his chosen list of deployment environments, the application provider or development team needs to ask:

Can we provide business functionality needed on our new platform(s) of choice?

How can we streamline the process of building this functionality to improve time-to-release, reduce our internal costs, and remain flexible for the next set of user requirements?

The ideal solution would be to tackle both issues using a single, efficient method of building functionality, ideally re-using functionality that already exists, and replicating this unchanged across the list of deployment platforms.


Micro Focus’ commitment to COBOL portability leads the way

To deploy business functionality across multiple platforms, Micro Focus tools are designed to help enterprise application providers build systems that are truly portable. Applications created for one platform can be re-used on a new platform essentially without change. These “applications” are the same tried-and-trusted applications that having been running for decades in COBOL.

Thirty years of industry leadership and investment in technology enables Micro Focus to shape both the COBOL language standard and COBOL’s implementation in a variety of products across a vast array of platforms. The Micro Focus approach maintains the portability of the COBOL language, irrespective of product or platform attributes.

The mainframe environment is subtly different. While the COBOL is very similar, the interdependency on transaction systems, mainframe databases, job control systems and other mainframe systems, make the portability of such systems a more substantial task. The mainframe offloading and rehosting tooling offered by Micro Focus has helped both ISVs and enterprises successfully modernize mainframe applications to a distributed world. Over 600 successful rehosting projects have been achieved through this approach.

Application development tools enhance portability

In terms of the development method and process, Micro Focus provides consistent and class-leading application development technology that enables today’s developer to analyze, develop, debug, test and deploy their applications across an array of platforms. The integrated development environments from Micro Focus allows for instantaneous edit/debug cycles, feature-rich developer tooling, running under new industry-leading frameworks such as .NET and Eclipse. Onward development from Micro Focus puts COBOL in the cloud and on Android.

This focus on developing and enhancing COBOL for both distributed and mainframe environments enables Micro Focus to offer an unrivalled level of portability in the enterprise application marketplace. It is one of the main reasons why COBOL continues to be the smart choice for application providers and development teams across the industry.

Next time you do a platform review and your application provider cannot support your new choice – ask them why they are not using portable technology that puts you at the centre of their strategy.


COBOL:  It’s easy to learn and easy to use.

Think about the last gadget you bought, and then think about how you got it to work. Did you put the device to one side while you spent some quality time reading the manual from cover to cover? Or did you rip it out of its packaging and try to start using it straight away?

It’s only natural to want work out how something works ourselves and, let’s face it, most gadgets are fairly easy to figure out.

There’s also the fact that maybe we don’t want to read the manual. Possibly over time we have learnt not to trust manuals, we shy away from technical information and prefer to avoid anything to do with techno-babble.

It’s the same story in the day job. We avoid having to “figure out” technical facts and figures, especially if we just have to stare at it, un-coached. We are drawn to things that make sense without too much effort, that are easy to understand visually and, if they are languages, that are easy to write.

The COBOL computer programming language stated its objective to be ‘easily understood’ a very long time ago. Its authors prescribed its value as part of its name: Business-Oriented. The ideal was that the business community could use this technology to make life easier. Targeting a previously ignored audience was the cornerstone of its success.

COBOL is structured in terms of its layout, and uses active English-derived constructs (ADD is ADD, EQUALS is EQUALS, PERFORM is ‘go and do’ etc.). These tell the reader at a glance what the code is trying to achieve. New Micro Focus employees are shown some COBOL code as part of their induction training and are asked to describe the code sample with two minutes coaching. Everyone succeeds because the language is a naturally intuitive construction that anyone can write.

As anyone can write it, it becomes possible to create low-cost high-availability resource pools to construct applications – with its logical structure leading to a fairly consistent implementation.

Consider defining some data: with COBOL the rules are pretty self-evident and quite explicit. For example, 01 item-a pic 99V999 is a data item ‘item-a’ defined as (a picture) a two-digit number with three decimal places. It is exact, straightforward and easy to pick up.

As anyone can read it the downstream benefits are equally significant. First, it means the resource pool available to work on COBOL systems is conceptually unlimited. There is no barrier to entry for future COBOL programming skills. This means a lot in terms of strategic planning and investment, and in terms of dollars.

Second, if anyone can read it anyone can maintain it. A second generation of programmers can code COBOL and also code in existing COBOL applications they hadn’t originally written. Also non-developers can at least follow the flow where it was necessary: QA staff can assist with code walkthroughs and debugging work, systems administrators can provide appropriate support functions and be more familiar with the applications themselves.

Third, the high legibility of COBOL avoids a major and common pitfall – namely that coders will simply rewrite something they do not understand in their preferred language. COBOL typically passes the comprehension test. As Michael Coughlan of the University of Limerick says, “It’s not a write-only language. You can come back years later and understand the code.”

COBOL became the dominant business language for very good reasons. It evolved as COBOL programmers picked up and added to existing applications, enabled by the fact that the language is easy to understand. “COBOL is one of the few languages written in the last 50 years that’s readable and understandable”, says Mike Gilpin, Analyst at Forrester

More recent language enhancements and modern OO syntax enables managed-code developers to cross boundaries quickly and support COBOL development as the constructs of Object Oriented COBOL will be familiar. Conversely, COBOL programmers need only acquire modest new syntax to consider providing COBOL business functionality as consumable objects.

Whatever the business requirement, COBOL remains one of the lowest-risk and lowest-cost options in terms of application provision, simply because it is easy to gain the skills to develop it.


COBOL is Adaptable

https://blog.microfocus.com/cobol-standing-the-test-of-time/

The hi-tech world of IT embraces and celebrates ‘new’ more than any other industry. New, creative innovations enjoy a meteoric rise in popularity and interest – seemingly overnight – for the potential benefits they can deliver to early adopters. What do Smart phones, Tablet computers, iPods, social media, and wireless networking have in common? They were all innovations of the last decade, and already we can’t imagine life without some of them.

In a market crowded with new entrants each year, existing and established technologies have to fight to remain current, relevant and valuable.
So how has COBOL, a sixty-year-old language, managed to remain a forerunner in the world of enterprise application development?

The answer lies in its adaptability. It evolved, and continues to evolve, according to the needs of the day by welcoming new phrases, new meanings, even letters, and by slowly retiring anything no longer used.

Consider the growing use of SOA and Web Services, and the range of technology elements – such as XML, WSDL, SOAP and others – the framework needs for things to talk together. Micro Focus was quick to market with tooling to allow the rapid creation of Web Service or SOA versions of existing COBOL applications.

These technologies have been introduced over the last thirty years or so:

  • UNIX
  • .Net
  • C
  • VB.net
  • XML
  • Eclipse
  • J2
  • HTML
  • Server
  • SOA
  • ORB
  • WEB
  • JAVA
  • C++

And these platforms and environments have come into being during the same period:

  • Mobile
  • Cloud
  • Windows
  • zLinux
  • OS/2
  • Linux

These platforms and technologies share a common thread – the investment that Micro Focus has made to ensure these new environments are accessible from the COBOL world in a meaningful, practical sense. In most cases, Micro Focus was first to market with product technology that supported the new ‘standard’ and enabled deployment to new environments.

COBOL continues to evolve to take advantage of emerging technology: In 1974, 1985 and 2002 the COBOL language standard was updated. Micro Focus played its part both by participating in the standards body, and also being one of the pioneers of the new standard from a compliance perspective. This is illustrated by the ‘industry firsts’ to come from the Micro Focus stable.

  • 1975 – COBOL compiler for microcomputers
  • 1980 – Visual Debugger 1982-COBOL for UNIX variants
  • 1984 – 32bit support 1985 – CICS emulation on the PC
  • 1990 – Assembler emulation on the PC
  • 1991 – COBOL compiler and development tools under Windows
  • 1995 – Object-Oriented COBOL 1996 – Native Windows IDE
  • 1997 – Internet COBOL application support
  • 1998 – IBM mainframe development system under Windows
  • 1999 – 64bit support 2001 – COBOL and Java mixed language support
  • 2003 – COBOL Web Services support
  • 2004 – Deployment CICS and transaction engine on UNIX/Linux
  • 2005 – Deployment JCL engine on Windows/UNIX/Linux
  • 2006 – Deployment IMS/TM engine on Windows/UNIX/Linux
  • 2007 – Deployment IMS/DB engine on Windows/UNIX/Linux
  • 2008 – COBOL language environment for Microsoft Visual Studio
  • 2009 – Rapid mainframe DB2 to Microsoft SQLServer migration capability
  • 2010 – Visual COBOL-deployment of applications into .NET, JVM and Azure
  • 2011 – Windows-based dedicated mainframe application testing platform

We now see COBOL applications written decades ago being deployed to cloud, .NET and JVM. Micro Focus’ commitment to its customers is most emphatically provided through its backwards compatibility policy: That any COBOL, anywhere, that conforms to the standard(s) will compile with the latest product. This guaranteed forward path serves to keep applications current and provides a low-risk environment for systems development. This contrasts starkly to other technology options where the code was good for a couple of years but had to be rewritten because a compiler release had changed.

The outcome is that COBOL can be easily used as part of a leading-edge technology strategy, and part of contemporary deployment architecture, using SOA, websites, Application Servers etc. One healthcare provider took its applications, built using COBOL development technology licensed in 1984, and re-used the business logic more or less unchanged as part of a program to provide web-based access to those business applications via SOA. The underlying COBOL code remained unchanged as the work invested in COBOL by Micro Focus over the years ensured that the leap to SOA could be achieved without changing the core code.

The future brings undefined generations of technology innovation into view, renewing the requirement for investment, innovation and certification by Micro Focus on behalf of its customers. From the advances in deployment options, including cloud and mobile devices, to supporting mainframe CICS application running natively in Azure, as well as moving to Windows 8, Micro Focus will continue to invest proactively to ensure customers’ future strategic decisions allow their existing investments to remain secure and protected.


COBOL Adoption & Survey Results

Roger’s adoption curve is a well known model which shows how new ideas and products get adopted over a given time-frame. Basically, things start relatively slowly, there’s an accelerated mid-phase where a majority of the audience ‘buy in’, and then there’s a decline to a small remainder.

Once over a certain point, a growing trend takes on a life of its own and becomes self-fulfilling. Commentators from Geoffrey Moore[ to Malcolm Gladwell have attempted to describe how to get up (and over) the steep initial slope of the adoption curve – the Chasm. Once you’re over this, though, and on an upwards trajectory the benefits are impressive. Buying decisions, particularly in risk-averse corporations, will go your way as businesses opt for tried-and-trusted solutions to their business pains. A winning formula will be re-used as often as possible, especially if the cost of bringing it on board in terms of skills and technology is relatively low.

Right from the outset in 1959 COBOL immediately presents an attractive proposition as a relatively low-cost, innovative IT power… before it was called IT, of course. The language’s ability to charm the business community lay behind its take up – after all, it wasn’t called the Common Business Object Language for nothing. Within a decade, long before the appearance of other languages we know today, COBOL was the ‘go to’ language of data processing for the business world.

Micro Focus and Vanson Bourne have surveyed the industry and drew some pretty illuminating statistics[ about the ubiquity of COBOL in the workplace. The global survey asked COBOL-connected architects, software engineers, developers, development managers and IT executives from 49 countries to determine and calculate the volume of COBOL application code running production systems, as well as the strategic importance of COBOL applications to their business, future application roadmaps, planning, and resources.

“For this year’s survey, Vanson Bourne set out to gather data from the IT community on COBOL’s continued relevance, in addition to getting a better picture of just how much COBOL is currently out there in use,” said Jimmy Mortimer, Senior Research Consultant at Vanson Bourne. “Whether this increase in code is externally driven or motivated by new technology or business transformation initiatives, it is clear that the importance and volume of COBOL in use continues to grow each year.”

Other data regarding overall volumes of COBOL code suggests that:

  • COBOL Market Shown to be Three Times Larger than Previously Estimated
  • Global COBOL Code Volume hits new highs: More than 800 Billion lines of code running on production systems and in daily use, far exceeding any previous estimatesNearly half of the survey’s respondents expect the amount of COBOL in use at their organization to increase in the next 12 months.64 percent of respondents intend to modernize their COBOL applications and 72 percent of respondents see modernization as an overall business strategy.
  • When asked about their company’s plans for COBOL and the cloud in 2021, 43 percent of the survey’s respondents stated that their COBOL applications do and will support cloud by the end of the year.

<iframe width=”560″ height=”315″ src=”https://www.youtube.com/embed/tDAYm-eN-_4″ title=”YouTube video player” frameborder=”0″ allow=”accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture” allowfullscreen></iframe>

This indicates COBOL’s place in IT and in the business world as a whole. This volume of code and level of investment – especially given the importance of some of the business functions it provides – creates a lasting heritage.

How much COBOL is really out there?

text over graphics - How much cobol is really out there?
Watch this webinar

Was the proliferation of COBOL over the decades inevitable? Was it because there was nothing else around? No. By being smart about its market position and its target audience, COBOL gave itself the very best chance for survival.

Over the years COBOL’s highly reusable nature has seen it pervade across the enterprise. After all, why write applications from scratch if the business function already exists? Why risk application failure and undergo the cost of investing in similar capabilities, when an existing one can be re-used and refined to do a new task? The answer is most people didn’t take the risk, and chose to exploit the COBOL systems they had.

Also, how did organizations whose reliance on COBOL deepened through a ‘re-use’ policy meet the growing skills challenge? In fact, it was simply down to COBOL’s ease of learning and highly readable format. These enabled resource pools to be flexed and scaled out easily. What’s more, its popularity – then without question – ensured there was a ready supply of programmers willing to take a role.

Today that skills pool may look markedly different – the programmers who cut their teeth on COBOL have aged, and subsequent generations of programmers have been brought up on different languages that reflect the changing IT landscape. Now, there is more code than ever before, more opportunities for re-use and continually evolving requirements to deliver existing business functionality into new channels and across new devices.

In short, the COBOL heritage is as valuable today as it ever was.


COBOL Jobs

The demand for skilled COBOL programmers remains strong. According to Simply Hired, COBOL jobs listings have increased over 100 percent since November 2009. Over 100 universities have recognised the opportunities this presents and have signed up to the Micro Focus COBOL Academic program which provides free access to the latest technology and teaching tools for enterprise application development. Around 9,000 students graduate every year with vital COBOL skills.

Contact Micro Focus to add your institution as an academic partner

Here is a list of existing partner institutions of the COBOL Academic Program 

The continued investment in COBOL over the years means that today’s IT teams can create exciting user interfaces using latest technologies such as WPF, JavaFx, HTML 5 or Silverlight to wrap around proven business logic implemented in COBOL. XML integration means that COBOL applications can be deployed as web services in the cloud as servicing applications, developed to run on iOS and Android platforms. COBOL’s place in the next generation is already proven.

According to research by the Standish Group, organizations consider re-using or “modernizing” existing COBOL-based systems to be a better option than re-writing or replacing the application with an off the shelf packaged solution – risking the valuable IP that was written into the COBOL over the years. For cost, risk, competitive advantage and time-to-market reasons, the value of the COBOL heritage seems set to last into the future.


COBOLs Robustness and validity

Who would go mountaineering in stiletto heels, or drive off-road in a Ferrari? Let’s face it, there are some tools that are just plain wrong for the task in hand. This is especially true in IT. Business applications need to be built in something that is robust and reliable. Who wants to face a user revolt when systems keep crashing or the wrath of the CFO when numbers don’t add up?

At the high end of enterprise computing there are key criteria that describe the technological requirements of the business systems.

The criteria can be summed up as: Robustness and validity, strong data manipulation, accuracy, speed and accessibility.

As you would expect from a Micro Focus blog, our assertion is that COBOL is the only language that meets all these criteria. It makes sense for us to take each one and show you how COBOL fits it.

The language used to create and support applications needs to be as low-risk and error-free as possible to support the business.

COBOL’s type-rich language allows data to be described accurately with explicit scope and limits. This richness means you can meet your corporate coding standards, ensuring consistency and accuracy across your organization and third parties, including partners and industry specific compliance requirements such as Basel II and (Insurance one). This applies to data management in the same way.

For example – a MOVE of number-a of PIC 999 to alpha-a of PIC AAA will invoke a warning.

The need to write robust code is addressed by type checking when you come to compile. This improves the effectiveness of the application creators, helping them avoid any unnecessary pitfalls and deliver more robust applications.

As you run the code, you can set switches to validate the running of the code, heading off any serious errors that may have crept in.

As the language lends itself to error-free coding there’s no need for you to write huge error checking routines.

Types are applicable to the business user, they reflect the concepts of the data the user needs, in the right format. So, numeric-edited types for even stronger formatting and type management, such as blank when zero, decimal point etc. This is taken care of by typing rules in the language so you don’t have to spend time formatting what gets displayed on the screen.

Here are a couple of examples:

Input ValueOutput Value
201001112010/01/11
  
-1234.5-1234.50

With these output items defined as:

77           numeric-edited-date-field                           PIC 9999/99/99

77           numeric-edited-bwz-negative-field        PIC –ZZZ,ZZZ.99

COBOL’s Numeric arithmetic accuracy

Essential for robust business applications, COBOL delivers arithmetic accuracy to 38 digits – that’s more than any other language.

An 18 integer number is defined simply as number-1 PIC 9(18).

Micro Focus supports 38 significant digits (i.e. both sides of the decimal point) in a numeric field.

You’ll get an idea of how COBOL trounces Java when it comes to the accuracy needed in financial applications in this blog.

COBOL’s Strong data manipulation

COBOL comes equipped with a range of capabilities to deliver stronger data manipulation, these include:

  • Faster data access than any RDBMS
  • Data files of a variety of formats             �
    • RDBMS
    • Indexed
    • Sequential
    • Relative
  • File size limits set by the operating system. In fact, the Micro Focus file handler has no limit on what it can read (the OS limit is a sizeable 2 ^ 64)
  • Data manipulation and reporting built in to the language with the SORT capability. This uniquely enables you to SORT and filter within COBOL without having to engage another tool or any extra steps.
    • Any element of any definition in any record can be used as the SORT ‘key’
    • Multiple file merging and record-level manipulation (even re-arranging the order)
    • Multiple output data sets to automate complex data processing with simple language controls
    • Massively faster than the alternatives

COBOL’s Speed

Speed is a key criteria for any business applications, they need horsepower to deliver both computational speed and batch support. COBOL is FAST!

Portable across a wide variety of platforms, COBOL offers deployment flexibility and can also be optimized for specific hardware, increasing performance and throughput. COBOL’s “code generator” exploits target platform technology to deliver optimal performance, at the same time the technology also enables the creation of fully portable executable code.

COBOL’s Accessibility

While the coding language has to deliver against all of these criteria, it has to be accessible and meet the demands of business. Programming languages don’t exist in isolation. They only deliver value in the hands of the coders, who in turn are only as good as their ability to align the application to a business need. To make a valuable business contribution, the language should also combine a state of the art environment for building robust apps, including latest features (Intellisense, rapid code/debug, UI builder) and be built on the latest frameworks (Visual Studio and Eclipse).

Figure 1- state of the art COBOL IDE based on industry-standard Eclipse and Visual Studio frameworks

Figure 2 – undefined items are automatically highlighted (red underline)

Figure 3 – Right-click to see options of likely statement or variable names (“Intellisense”)

Not only does this make the language more relevant to the business context, it makes it easier to learn and maintain.

In short, COBOL is the language of business because it is designed with business in mind. Business relies upon and trusts technology that most closely reflects and supports how it sees the world. COBOL has been consistently developing and evolving to meet the changing demands of business for the last fifty years. Investment in the technology by Micro Focus over the last thirty-six years has ensured that COBOL continues to deliver against the criteria that business applications require, and will continue to do so for decades to come.


The Future of COBOL is NOW

As IT spend declines, innovation is expected to soar and IT departments have to exploit leading edge technologies for application deployment to stay ahead of the game. With new technologies comes a need for new skills without losing those that already support existing critical systems.

The future of COBOL lies in Micro Focus Visual COBOL, an integrated development and deployment tool that helps you deliver more from your existing core systems investment.

We have identified the five core attributes the IT infrastructure has to exhibit to support current and new challenges as cost-efficiently as possible.

1. COBOL’s Foresight

Ensuring your enterprise applications meet tomorrow’s needs today

Whatever your chosen programming language, it has to keep up with the changing IT landscape. COBOL can underpin contemporary deployment architectures, leading edge technology and composite applications within Java, C++ & C#.

COBOL applications written more than a decade ago are now being deployed to cloud, .NET and JVM. Visual COBOL enables you to exploit new market opportunities and extend your existing investments by deploying current applications onto new platforms, including .NET, JVM and the cloud as well as Windows, UNIX and Linux platforms.

2. COBOL’s Heritage

Five decades of heritage, thousands of organizations, billions of lines of value,

New application development rarely starts from a blank sheet of paper. Innovations often arise from delivering business applications through new channels. Using the extensive business logic built into existing COBOL applications in new environments for decades to come will maximize both investment and market opportunity.

  • Its highly reusable nature is why COBOL permeates the enterprise. Why write new if the business function already exists?
  • Because it is easy to learn and highly readable, COBOL enables resource pools to flex and scale up easily
  • Alternative development languages can rapidly access COBOL value using native semantics and data types

3. COBOL’s Portability

The original write once, run anywhere technology

End-users only want one thing: Functionality on the platform of their choice. It’s up to development teams to ensure that they deliver functionality that’s streamlined to work on the right environments.

Our COBOL technology is designed so that the same application will run unchanged across a variety of platforms and operating systems, without the programmer having to worry about the specifics of the environment. Because it’s platform independent, the Visual COBOL deployment technology means developers can focus on building application value rather than on the nuances of the operating system. Visual COBOL provides true portability for applications to ensure that their value endures long into the future.

4. COBOL’s Fitness-for-purpose

Engineered for building great business applications

Today’s front-end applications need development tools that sit in a browser or other thin-client interface, the back-end needs strong and reliable IT infrastructures that offer robustness and validity, strong data manipulation, accuracy, speed and accessibility. In short, something fit for your business needs.

Visual COBOL takes advantage of COBOL strengths as a business critical programming language – numerical arithmetic accuracy to 38 digits and strong data manipulation and SORT capability – and provides an intuitive, unified environment for building robust applications.

5. COBOL’s Readability

Ease of learning, reading and writing enables you to focus on business

Change is inevitable, so why make updating and maintaining applications harder than it needs to be? As a language COBOL is simple to understand and doesn’t necessarily require prior language-specific experience. This contrasts with many programming languages where, even with the skills to write it, the code is hard to understand.

As Visual COBOL integrates with industry standard IDEs such as Eclipse and .NET, it puts COBOL at the finger tips of all your programmers, putting COBOL in the environment your developers are familiar with and using tools they already work with.

Learn more about Micro Focus and our portfolio of Application Modernization products

Avatar photo

follow me on twitter or connect on LinkedIn

Share this post:

15 Comments

  • A very good description of the way COBOL has evolved whereas earlier languages, such as Assmbler, have finally withered and died (in terms of application development). There are currently plenty of COBOL developers supporting these applications, however, how many organisations have a strategy in place to continue this in 5, 10, 20 years time? In other words, where are the COBOL programmers of the future going to come from when everyone seems to want to move into, for example, Java?

  • How is possible to study COBOL ? There are no more limited or student edition of compiler or IDE.

    • Micro Focus

      Great question! Thanks to its readability, COBOL is an easy language to learn. In fact, if you are skilled as a programmer in more or less any other 3GL language, you will be able to learn COBOL very quickly!

      Micro Focus runs an academic support program through hundreds of universities so students can get their hands on COBOL. We are also aiming to provide an updated “Personal Edition” that might also be useful. Finally, Micro Focus provides some training courses for COBOL. Contact us via http://www.microfocus.com with your requirements and we will be happy to discuss what you need.

  • Some may read news articles and news stories about the CRASH report and conclude that COBOL is good while Java is bad. This is an oversimplification of the commentary and analysis, but it summarizes the gist of some of the commentary and analysis. However, a reading of the Summary and some independent analysis might lead one to a very different conclusion.

    One can find many quotes online, often without any source documentation, that COBOL usage in the business world accounts for 80% of the world’s computing business—private sector, public sector, and higher education. The Gartner Group is frequently cited as a source for this number, but Gartner Group data and research is not freely available to the public to confirm this number.

    One can browse a lot of Gartner Group research online and free of charge. Summaries of research can be viewed, and keyword searches sometimes reveal perhaps poignant observations.

    The COBOL wiki page cites the 80% number, and the date of the pronouncement is claimed to be from 1997—more than 14 years ago. Many COBOL programmers working in the industry between 1997 and 2012 will attest to the disappearance of many COBOL jobs through outsourcing, the conversion to other programming languages, the conversion to software packages, and perhaps other reasons. Assuming the 80% number was correct in 1997, one should probably view the 80% number with a great deal of skepticism in 2012 and beyond.

    In the CRASH report, COBOL applications account for just 11%—50 out of 745—of the applications submitted and assessed by Cast Software. It seems reasonable to conclude that either COBOL is not used as widely as it once was, or COBOL was not represented proportionate to its market share, or both. If COBOL was not proportionately represented in the CRASH report study, there is likely any number of reasons why.

    The CRASH report indicates no difference in quality between in-house development and out-sourced development. This conflicts with the experience of many senior COBOL programmers.

    The average price of coding violations was assessed at $3.61 per Line Of Code (LOC) with COBOL being the cheapest at $1.26 per LOC and Java the most expensive at $5.42 per LOC—see Figure 22 of the CRASH report. However, because COBOL is a verbose language this number is very deceiving. The CRASH report states the average software component contains 20 to 50 LOC while the average COBOL component contains over 600 LOC. Lines Of Errors (LOE) are not reported, but if LOE is proportional to LOC, then COBOL errors could actually cost between three and seven times more than Java errors.

    The CRASH report summary is not the full report, and thus it is difficult to make concrete observations. However, given the extremely tiny subset of software applications analyzed—just 745 from the U.S. or perhaps the globe—it is difficult to treat the report details as absolute.

    • Micro Focus

      Thanks for your reply. It is great to hear from readers who have found our blogs of interest enough to want to comment. All ideas are very welcome.

      It is worth reinforcing the main thread of the blog, here, which is less questionable perhaps, which is the necessity for IT organizations to find ways for their core application logic and business systems to find ways to integrate, co-exist and continue to add customer value. COBOL has been integrating with all technologies around it for decades now, so the prevalence of Java, for example, as a language of choice for new application front-ends, is merely another support point that COBOL has quickly and seamlessly embraced. Similarly so for C# and so much else. COBOL enables organizations to get on with the business of serving its customers better, rather than worrying about technical challenges or architectural policy. Micro Focus’ investment in the portability and “future-proofing” of the language and ecosystem (about which we have blogged recently) only serves to reinforce our belief that smart IT is all about collaboration. So our assertion is that language choice isn’t about what’s good or bad, but about what makes most business sense.

      Regarding your comments, we would certainly echo the view that industry “reports” such as the CRASH report and even studies undertaken by larger organizations such as Garter, are always by their very definition, going to be selective to some extent. Additionally, information contained in Wiki sites, journalist reports, and perhaps most self-evidently information from vendors themselves, are going to rely on a viewpoint that isn’t necessarily as balanced as might be possible from a truly independent commentator. It was merely the intention of the blog to cite reference points that were available at the time to act in support of a point being made. It was our hope that some of the information cited would support the arguments being made rather than detract from them. You raise a great point that that it is important to draw one’s own conclusions about how much relevance to attach to individual references.

      Back to the blog. We’re happy to hear more stories about composite COBOL and Java/C#/etc applications and how they have made a business difference and welcome any more comments. Thanks again for taking the time to comment.

    • Hi Ken,

      I s’pose I better make it clear that I don’t know you and there was no chance of us colluding on our posts 🙂

      To be fair to Micro Focus, they deserve credit for posting comments (even dissenting ones) on what is actually a corporate blog and keeping an open and fair discussion.

      Although I don’t personally put any credence in the Gartner figures, I don’t think it really matters whether there is a HUGE COBOL legacy or there isn’t. That legacy base is being eroded every year as people vote to move on.

      The concern I have is that all possible value gets leveraged out of that legacy BEFORE COBOL is discarded. Micro Focus provide an excellent implementation of a fully Object Oriented COBOL compiler for .Net (Visual COBOL) and this is definitely a step in the right direction when it comes to “objectifying” legacy COBOL.

      The future is in LAYERS and OBJECTS.

      At least in my opinion, Procedural code, whether it is in COBOL, Fortran, RPG, or PL/1 is NOT the best tool for implementing that.

  • Hi Derek,

    I visited and read the post as you requested in comments on my DZONE article.

    I enjoyed your article here but I would have to take issue with a number of statements. I’d enjoy debating some of this with you over a pint , in a friendly way. However as I am in NZ, that is unlikely to happen… 🙂

    I have made a few quick comments below, but I think you’d see my position better if you read the piece I wrote recently on the relevance of COBOL and the implications of moving on from it. Here’s the URL: http://primacomputing.co.nz/cobol21/COBOLRelevance.aspx

    I migrated away from COBOL to C# and .Net about 4 years ago and since then I have helped a good number of other people do so too. I really do understand the issues in this and I have no axe to grind about compilers or flavours of COBOL.

    OK, quick comments on the above…

    Some of the claims are unsubstantiated and unsubstantiable. I don’t personally believe there are more transactions processed in COBOL than hits on the Internet daily. There MIGHT have been for a brief period around 10 years ago, but most of this kind of hyperbole is based on a Gartner report which came out around that time (and has since been disclaimed by Gartner themselves, as impossible to verify), where they claimed billions of lines of code etc.

    However, I don’t wish to argue the relevance of COBOL on those grounds anyway. The inescapable fact is that the paradigm has changed and COBOL is no longer the best tool for the job when it comes to development for distributed systems.

    COBOL still remains excellent for batch processing (which is based on the centralised single processor architecture which saw us through most of the last century), but modern systems are designed and distributed in ways that allow load levelling, parallel processing, support for multiple cores, all of which make batch processing redundant or at the very least, largely unnecessary..

    There is, of course, a HUGE legacy of Business Rules bound up in COBOL and the refactoring of this functionality is of major concern for organisations moving on from COBOL.

    (My personal concern with this is that some companies are being told all they have to do is recompile for .Net and their worries are over. It is nowhere near that simple; the legacy needs to be refactored into objects that can run in an OO world (like .Net or Mono), as OBJECTS and in LAYERS, rather than a single monolithic block of code that does everything..) Fortunately, a good deal of this can be done by tools, which removes the tedium and the errors in doing it by hand.

    As for having stood the test of time, there is nothing wrong with COBOL as a language, but times change. It isn’t just fashion, there are very sound reasons as to why you might move off COBOL.

    You said it costs less to maintain per line than Java does but if every line of Java is equivalent to 5 lines of COBOL, that doesn’t mean much…

    For myself I have found approximately a 4:1 ration between lines of C# and COBOL. 4000 lines of COBOL can usually be done in around a 1000 lines of C#. While I’m not suggesting this is a scientific fact, it is based on empirical evidence from a COBOL base of around 500,000 lines.

    Java is free. C# is free; you download it for nothing, tuition in it is free, (There are channel 9 videos on MSDN to help people get started.). Support and code samples are free. (I have never failed to find what I was looking for using Google, in seconds – compare this with wading through a Help file). The equivalent of all these things in COBOL costs thousands of dollars.

    I don’t think you can “justify” COBOL on a cost basis…

    The subject of what we do about COBOL is very dear to my heart and I have a lot more to say about it than I can possibly cover here (or even on DZONE). However, I’ll be publishing more stuff in the near future and stepping back from the technical level to a more management oriented examination of the issues.

    Cheers,

    Pete.

    • Micro Focus

      The previously-posted blog features a number of references and citations that are true to the best of our knowledge. Some are quoted from secondary sources but in the absence of industry-wide empirical evidence, Micro Focus is using references that are if not cast-iron facts they are at least generally viewed as credible sources. One could easily debate the veracity of all but the most primary evidence as dubious in some measure, but to strip the blog bare of any reference points would, it was felt, detract from its value. This true for the Gartner reference and also citing the study undertaken by CAST. Micro Focus has no reason to believe that the facts as reported are in error.

      Micro Focus is posting the blog in good faith and on the basis that the reference material is true, but it accepts that some readers may find some details difficult to agree with. Such is the nature, to a great extent, of blogging.

      As for COBOL’s remaining relevance as the ‘best tool for the job’ for development for distributed systems, it is important to note here that the accepted wisdom for many organizations –including hundreds of our customers – is to use a mixture of components within enterprise applications. Typically development of front-end components and UI uses a variety of tooling but is typically often exploiting later technology such as .NET / C# or Eclipse / Java, which is highly capable and feature rich. To use a COBOL based alternative is not recommended even by Micro Focus, though if COBOL skills and COBOL-based UI’s already exist in abundance, there would be little reason to change perhaps. This depends on the customer’s own architecture, skills pool, and other considerations. But for sure the future of front-end development needn’t be COBOL based at all.

      It more on the back end where COBOL comes into its own. The response mentioned batch processing power, and that’s certainly true. Micro Focus COBOL has a proud heritage, based on the robust nature of the language, of handling massive data processing tasks, and ably handling complex arithmetic tasks, as one would expect of a business-oriented language. Furthermore, COBOL back-ends are capable of supporting a variety of front-end applications, acting as the service to a range of clients if you will. This allows traditional client server set-up, web portals and even now mobile devices to access the same service, running in COBOL to provide the same functionality to a variety of consumers through a variety of channels. Recent public demonstrations of this technology at the Micro Focus Developers’ Conference in Dallas, April 2012, showcased some of this new capability.

      Finally, a point about the driving force for technology choice. The decision regarding technology usage is a means to an end and the end is a stated objective provided by the business. Therefore the broader context of COBOL’s continuing value is a business one. COBOL was designed for the business and continues, in many, many cases to serve those businesses well. Does is need to co-exist with other tools that do particular things better? Absolutely. Does this mean that it is no longer relevant? Absolutely not. Provided business requirements such as fast time-to-market, good ROI, embracing new platforms and environment to reach new markets with existing business functions, unifying development processes and a variety of other challenges remain on the CIO’s to-do list, COBOL has a significant part to play in the success of an organization.

      • I think this is a fair statement of a viewpoint. Kudos to Micro Focus for posting comments.

        I couldn’t agree more that the Business (should) drive(s) the IT department; my comment would be that Business has changed significantly since COBOL was invented. 🙂

  • I work on a big Oil & Gas company which still heavily rely on COBOL running on mission-critical Solaris 10 systems for its monthly production reports. Sure the front-end has been redesigned in Java, but I don’t believe it would be feasible to migrate the whole back-end. It’s a lot of complex batch code that’s running well for years. I’d expect Mico Focus to keep its support on the Solaris platform and finding ways to take better advantage of SPARC high thread counts.

    • I think there are still MANY sites that rely on COBOL for reporting and Batcch Processing. (Applications where a centralised processor is fine…)

      However, my personal belief is that Batch Processing is a technology of the past and new systems will probably not incorporate it.

      I know this sounds like heresy and the reasons I arrived at such a conclusion are too many to go into here. All I’ll say for now is that a modern Corporate data resource should reflect the real world in Real Time and we have the technology now to realise this. When systems are designed this way, Batch Propcessing is largely obviated. (Transactions are consolidated and summarised as they occur, background threads run to provide ad hoc consolidations for ANY time period, not just weekly, monthly etc. ) Reporting can use Data Warehousing and BI tools that are specifically designed for that; there is no need to be counting filler bytes in COBOL printlines…)

      I have no problem with the site you work on, Az. SPARC is very powerful processing and what they are running is working for them.

      But I’d be surprised if they continue to develop new systems in exactly the same way they developed the old ones…

      Pete

      • Having worked on COBOL systems in the eary eighties , transaction processing systems and VAX VMS based cluster systems we would spend a lot of time in ensuring that the hardware was used effectively.
        Cost and business risks are always relevant and its far more easy to provide production support for COBOL based systems.
        Like biological systems , the evolutionay efficiency of cost and efficiency in rolling out bug fixes will ensure that COBOL will continue to be relevant for enterprise business systems many more years.

  • I used Micro Focus Cobol in the mid 90’s. At the time I was in the EDI development group, and was responsible for developing the 214 Shipment status screens in CICS on a IBM/VSE. I found some floppy diskettes that had the product on it and a guy who worked there said he tried to use it, but mainly for DATASET download and manipulation. I loaded it on my PC, and honestly, 3 months later had a fully working CICS application on my PC down to the TSQ’s. It was great, and I could debug anything. I uploaded it to the mainframe, and I am not kidding, it worked flawlessly! Since then, I have wished for that software at several companies but haven’t been able to get it. The Micro Focus Cobol has been thru several company evolutions, so I don’t even know if it is the same product. –Thanks

  • Hi MicroFocus,

    Do we have cerification in Micro Focus COBOL. if yes could you please let me know the details.

    Thanks for your valuable suggestions.

Leave a Reply to Pete Dashwood Cancel reply

Your email address will not be published. Required fields are marked *