Do I really need to learn Javascript?

Javascript has gone from a mechanism for adding tweaks to web-pages to a key implementation technology for building web applications, and even server back-ends via technology such as node.js.

Javascript has gone from a mechanism for adding tweaks to web-pages to a key implementation technology for building web applications, and even server back-ends via technology such as node.js.

Javascript still divides the programming community. Many C++, Java, & C# programmers find it a very uncomfortable experience: lack of type safety, a single numeric type (floating point), no real classes (it has a different inheritance model). There a various tricks to make things look like real classes, but they don’t feel natural.

Traditional programmers look with horror as experts like Douglas Crockford explain why



 status: true


is not the same as:

 return {

 status: true



The new generation don’t seem to have a problem with it though. But aren’t they just creating a mountain of unmaintainable code that will get quickly thrown away and re-written?

Experts around the world acknowledge Javascript has many short-comings, yet still it blunders on, unstoppable…

So what does Javascript have going for it?

Firstly, it’s the most cross-platform language – and it’s always platforms that drive languages: the mainframe drove Cobol, Unix drove C, the iPhone drives Objective-C. As devices get more powerful, more can be done locally on the device. Code that was previously on the server might now be on the device. How many languages can we genuinely get code re-use from across such diversity?

There’s a low barrier to entry – you just need a browser and a text editor. It’s also fun. Within minutes you can be playing with map controls and other cool stuff. Almost everything has a JS library.

The language is also well suited to it’s environment: e.g. manipulating the HTML DOM, and asynchronous call backs, especially for REST services returning JSON

There are ways to tame Javascript. JSLint catches many errors. Google’s JSDoc annotations, and Microsoft’s Typescript augment some type safety. Typescript is more compact, and Visual Studio has good Intellisense support, but as a product of the “evil empire” I suspect adoption may be artificially limited. Frameworks like JQuery and EXT-JS try to standardize browser behaviour.

The only way to be sure is to run it.

However, fundamentally Javascript is a run-time language. Everything is dynamic. Further, its run-time environment is a browser, or an application containing a browser, and these can behave differently. The only way you’ll know for sure if something works is to run it, and run it on lots of different browsers & devices, and keep running it even when you code doesn’t change, because something else might.

Which means the burden on testing changes completely. It cannot be an after-thought. This is where tools like Silk are extremely useful.

Atlas provides a very fluid UI. It’s a Javascript application, interoperating with the server via REST services. We test it using Silk’s State Driven Testing feature, which means we can build the tests are we build the Javascript, and then test it automatically on Chrome, IE and Firefox (various different versions).

So do you need to learn Javascript?

Yes, I think you need to take a look at it, and flawed as it is, you may get hooked. Refreshing to see that Doug Crockford has grey hair, and seems to be coping just fine.

But be prepared to get a lot more serious about testing as well…

Mark Conway


E-commerce load testing during the off-season

Summer – the e-commerce off-season – time to get those servers in shape!

It happens every year. I exit the holiday season with some extra weight and I then spend the next three months getting ready for my summer “peak” season.

It’s a vicious cycle of gluttony followed by desolation and exercise. Ugh.

Just as most of us use our “off season” to get ready for when we need to perform, the systems that run businesses need to do the same. For retailers selling goods online to consumers, the typical off season are the months leading up to Black Friday and the subsequent Cyber Monday.

As I’ve outlined in the previous webinars, namely how “7 seconds can cost you $7 million”, user expectations around performance are increasing. Attention spans are decreasing causing frustration levels to increase as shoppers inundate retailers with web and mobile traffic. Some interesting stats include:

  • The average online shopper expects web pages to load in 2 seconds or less, after 3 seconds, up to 40% will abandon the site
  • 74% of users will abandon a mobile site after waiting only five seconds for it to load
  • Once visitors leave, it’s very difficult to get them back. 88% of online consumers are less likely to return to a site after a bad experience
  • 38% of UK online shoppers abandon websites or apps that take more than 10 seconds to load

It’s important for organizations getting ready for the retail peak season to understand what will happen when users swarm to their sites. The only way to figure this out is by doing intelligent load testing. Load testing will simulate hundreds, thousands, and in some cases, millions of users to determine where bottlenecks might occur. These simulations should also include mobile speed and device simulations as more shoppers are using their smartphones and tablets as the primary point of sale.


With less than 126 days until Black Friday, it’s time to give those servers a workout with load testing that will ensure frustrated users are converted into happy repeat customers.

Archie Roboostoff


HTML5 – A blessing for developers, a curse for quality teams

When I started tinkering around with mobile development, I found myself in a whole new world. A world that, frankly, I started to really like. Both the iOS and Android SDK environments contain controls and reusable elements that made me look like I actually knew what I was doing. Within a few hours, with the help of the good people at treehouse, I had built both an iOS and Android app that I was able to further hack and customize.

When I started tinkering around with mobile development, I found myself in a whole new world.  A world that, frankly, I started to really like.  Both the iOS and Android SDK environments contain controls and reusable elements that made me look like I actually knew what I was doing.  Within a few hours, with the help of the good people at treehouse, I had built both an iOS and Android app that I was able to further hack and customize.

As I dove further into this new mobile world, as with most development learning curves, I found myself realizing how much more I needed to learn to truly master these new platforms.  Quickly my dreams of the next great app making me billions were crushed by reality.

I then realized something, if I were to start a small company, I would need to hire experts on all the major platforms I would support.  Most likely I would need Web developers, Android developers, and iOS developers with separate code bases and specific skills that, outside of the overall flow and design, couldn’t be shared.  Sounds like a recipe for delayed products and increased costs over time.

I meet with many customers who are all across the mobile adoption spectrum ranging from “we’re thinking about this” to “we’ve got 9,000,000 users on our app.”  These customers are now starting to realize this same issue and are, or shall I say, were, struggling to fix the issue.

Enter HTML5

While the usage of HTML5 in Web based applications isn’t a new concept, what is relatively new is the usage of HTML5/Hybrid mobile applications.  To those who haven’t heard of this, HTML5/Hybrid applications have the native application container wrapped around a UI/Logic layer that is reusable HTML5 with javascript and CSS.  The thought behind this is that most of the HTML5 will be reused across all devices and browsers.  One of the better examples of an HTML5/Hybrid mobile application would be Netflix.  According to Netflix, they chose HTML5 because, “HTML5 also means that our world class UI engineers can seamlessly move between working on our website, our mobile experience, and our television-based applications.”

With HTML5, developers can support more applications with native functionality and work on the same codebase with shared skills.  According to Gartner, by 2015, 50% of the applications that would have been native in 2011 will be HTML5 applications.  To respond to the demand, HTML5/hybrid frameworks have emerged such as Phone Gap, jQuery Mobile, appMobi, and many others.  A good site to see which might be right for you is located here.

While HTML5/Hybrid applications give developers a fast track to sharing skills and delivering better products on more devices and browsers, the burden now shifts to the quality teams.

Native applications with native code targeted at the device can be individually unit tested and recorded and replayed with automation.  The UI layer was an important aspect but only used to verify functionality.

With HTML5/Hybrid applications, the shared codebase evolves itself based on the container of the client using the HTML5.  Not only do QA teams have to test the functionality as usual, but now they have to visually verify that the app looks, responds, feels, acts, and performs as it should on devices and browsers.


As if QA teams didn’t have enough to do!

This is where Silk’s ability to do both cross-browser and cross-device testing eliminates the burden to QA teams.  Cross browser testing ensures applications look and function correctly across the major browser spectrum.  One test script that challenges the HTML5 applications and displays any anomalies visually so the QA tester and quickly isolate and identify issues.  With Mobile testing, Silk brings the same concept but instead of testing across browsers, it tests across devices.

Both these technologies give QA teams the ability to quickly create a visual test scripts, replay those tests across all supported platforms, and visually see what the end user would see ensuring that HTML5/Hybrid applications have the highest levels of quality.

Just as HTML5/Hybrid applications help customers do more with less resources in development, Silk helps QA teams respond to the increasing challenges presented by the usage of HTML5/Hybrid applications.

The requirements bell curve

Requirements have a shape – a bell curved shape. The more “agile” an organization is, the flatter the curve will be…but the curve is always there.

Requirements have a shape – a bell curved shape. The more “agile” an organization is, the flatter the curve will be… but the curve is always there.

Requirements Bell Curve


Generally requirements start as a small definition of business need. They might originate from any number of sources… a different requirement, an email, an image, a defect… but they have a small seed of a start, then grow. As those who manage requirements, we should be defining just enough detail to explain the need to others then stop – any additional detail captured is “waste” until the need is agreed to.


Once the high level need is captured, supporting detail is added to assure the need is clear and provides the right clarity for different roles in the organization – user, executive, developer, business analyst, tester… This process will happen with varying detail for each organization. If the organization is very “agile” the level of definition may be light. If the organization is more structured and follows rigorous upfront processes, the requirement will be defined in depth with different perspectives (use cases, functional specs, technical requirements…). The key here is to only define as much upfront as needed, anything more is “waste”… keep the curve belly as short as practical.

Small again…

Once the target need is understood and you have consensus from those who need to provide it, priority requirements are broken down into “units of delivery”. This is done to accommodate the team working to deliver – their schedule, their staffing… Sure, there is often overlap between requirements (units of need) and stories (units of delivery), but the main point is that the development team creating the software works in small consumable bits that provide attainable mini-functions. They don’t work to deliver requirements.

I can guess what your next question might be… so what?…yes, the idea of a “Requirements Bell Curve” is not earth shattering or paradigm shifting. Having a model does however aid in conceptualizing something that is generally a bit more abstract…

We undertake software projects to provide business value. We define the need, then work to deliver it. They key is to only define as much as is truly needed to understand, achieve consensus and drive delivery. Any effort beyond that is waste…Work to keep your “Requirements Bell Curve” as flat as possible. If you’re looking for a great tool to help – check out Atlas on our website.

Mark Kulak


The Development Manager’s conundrum: Do even more, with less. Faster


Sound familiar? We’ve heard this from so many of our customers. They are trying to tackle the seemingly impossible – increase innovation to supply customer demand, while maintaining what already exists. To push the boundaries while keeping the lights on. This blog highlights the challenge and suggests an answer. Because we believe that Development Managers responsible for delivering COBOL applications really can do more, with less – and faster.

(For the purpose of this blog, I’m focussing on COBOL applications built on distributed environments such as Windows, Unix and Linux – but if your COBOL applications are on the mainframe, then take a look at this blog[m1] ).

 The Development Manager’s Enigma

COBOL is modern and agile. Discuss. Well, it will be if it can resolve the two fundamental application development challenges that our customers are talking about. They are:

1.      Keeping the lights on

We’re told that the majority of resource is needed just to keep the wheels turning. Maintenance of existing applications is a must, and there is a major backlog to make application improvements.  According to Gartner, the overall cost of ‘IT debt’ is projected to reach $1 trillion by 2015. Forrester cites that 70% of IT budgets are spent on maintenance tasks. Big bucks, big problem.

2.      Delivering innovation

Staying in business is all about keeping up with industry trends. It’s a must. Doing nothing is going backwards. Tech-savvy consumers are forcing the adoption of new technologies such as cloud, mobile and new IT architecture.  If businesses refuse to embrace these technologies, their customers will look elsewhere.  And they won’t be back.

Doing one without the other is not enough. So, the two challenges are essentially one: Keep the lights on and deliver innovation.

It’s your choice

Typically, there are four approaches to addressing these challenges:

1. Do nothing

Carrying on as normal has some merit. No action, no risk. But if you aren’t able to keep up now, then it won’t provide you with the step-change in business agility that you need. Inertia and performance don’t mix.

2. Rewrite

Many customers tell us they consider rewriting their applications in another language. However, this is timely, costly and high risk – with as many as 75%[1] of all rewrite projects failing. Keep looking.

3. Replace

Another favourite is replacement with an off-the-shelf package. It might sound appealing for a quick fix, but what happens to the decades of business intelligence and IP built up in your existing applications? You might lose competitive advantage. Additionally, our experience tells us that approximately 40%[2] of replace projects are cancelled.

4. Revamp

Naturally, this is the option that we advocate in most situations. Revamping means reusing your existing investments – your people, your processes and your existing applications – to create a new, improved environment. Because COBOL is modern and agile, it enables a fresh approach to how you build and deliver. This is the key to addressing the Development Manager’s enigma.

Maintain and innovate

COBOL is modern and agile. Still don’t believe me? Here are a few examples from our customers who have tackled these challenges, and with great results.

Addressing the COBOL skills shortage is one of the first hurdles – development teams often work in siloed development environments, broken down by programming language or the tools they use, which can inhibit application development. Using Visual COBOL, c# programmers at Nationwide Insurance were productive within 1 hour, simply because they were developing COBOL applications in Visual Studio, a modern IDE with which they were familiar. (Visual COBOL can also be developed in Eclipse).

Because traditional COBOL can be developed and maintained in modern environments, development efficiencies are also a key benefit. Using Visual COBOL, OM logistics saw a 30% improvement in efficiency.

These skills and efficiency enhancements mean your team can spend less time fighting the backlog, and more time innovating to supply consumer demand. But how can COBOL help you innovate and embrace disruptive technologies?

Well, because COBOL is modern and agile, you can deploy COBOL applications onto the latest platforms and newest technologies. Here are some great examples where our customers have done just that:

  • The Treasury of the Republic of Cyprus saved €250k per year taking their existing COBOL application to HTML5 to deliver a mobile web application.
  • Acciona Trasmediterranea saved 70% of IT costs and reduced time to market by 25% taking their existing logistics application to the cloud.
  • Zucchetti, a Human Resource application provider embraced modern IT architectures to speed up the adoption of .NET and JVM for COBOL application deployment.

Clearly most innovations are possible – it’s just a matter of finding the skill and resource to be able to deliver them.

Now do you believe me?

So – are you converted? I hope you can see that COBOL is both modern and agile. That it can deliver development efficiencies of up to 30% and reduce time to market by 25%.

What do your COBOL applications do and how could you modernize yours? If you want to learn more, take a look at how many of our customers are already delivering innovative solutions with modern and agile COBOL:

We’re all going on a … modernization journey?

The Micro Focus modernization journey includes Knowledge, Develop, Quality and Deploy leading to improved IT results


As a long-serving staff member of three whole weeks’ service, I’ve been able to get to grips with the Enterprise story. What I haven’t been able to do is make any vacation plans. They’ve had to be shelved for now.

Perhaps it’s the unfulfilled desire to get away for a week or two that’s been colouring my thinking, but I’m seeing several parallels between the Micro Focus Enterprise story, and the holiday journey I’m yet to take. Bear with me.

The route map

For me, every vacation starts with a plan and ends with filling a suitcase and jetting off. In between, would-be travellers must shop around for the best deal, book the trip, check travel restrictions – and more often than not, checking TripAdvisor to make sure the food’s edible and the rooms aren’t falling apart. On a personal note, I might also take a quick look at a government website to make sure my holiday destination isn’t at war with anyone. After that, it’s down to the journey.

The modernization journey for Micro Focus customers also includes stages of planning, preparation and careful checking before they are ready to deploy modernized core applications. Many of us draw up checklists to ensure successful holiday planning. The Micro Focus modernization journey includes Knowledge, Develop, Quality and Deploy with the ultimate destination the sun-drenched beach we call ‘improved IT results’.

Here’s what I have discovered…

To begin: why modernize applications?

According to Gartner and others, about 70% of the IT budget for many organizations are committed to ‘business as usual’ priorities – ensuring systems are maintained, up-to-date and compliant. These activities leave little resource to support innovation demands, such as big data, Cloud, web and mobile access. So, in other words, it’s a ‘staycation’. No expense, but no progress either.

But everyone needs a holiday, right? So if you want to head for pastures new, you have three options: rewrite, replace or what Micro Focus calls revamping. This is all about retaining your skills, processes and applications, but taking a new approach to how they are built and delivered. Harnessing the latest technology will free-up resource, expertise, and budget, to deliver more of that innovation. Revamping approach can be used alongside a re-write or replace strategy to help mitigate risk.

To return to our analogy, your options now include an adventure trip, a spa break, or a beach vacation. And with such wildly varying locations, the journeys are likely to be different every time.


Just as reliable research is key to a good holiday, accurate application information is vital for the success of the modernization journey. Micro Focus’ analysis capability provides business and technical insight into applications, reducing maintenance effort by 15-20%, and accelerating modernization projects. In vacation-planning terms, it’s like having a personal travel agent.


Developers are often limited by their environment, especially in terms of opportunities to focus on innovating. The Micro Focus Enterprise product set almost revolutionizes the z/OS application development by exploiting contemporary IDEs. This helps developers to be significantly more productive. It liberates subject matter experts to support innovation projects and enables new developers to become productive sooner.

In vacation terms, using a limited environment is like  taking a cheap package deal when you really need all-inclusive luxury. Which is why boosting developer productivity feels like an upgrade…


Micro Focus enhances quality in two ways – firstly by introducing flexibility into the testing environment. Today all z/OS application testing is conducted on z/OS partitions. Through Enterprise Test Server, Micro Focus offers the unique ability to conduct a subset of testing under Windows, to remove QA bottlenecks, and improve quality while reducing testing MIPS[1]. While you can’t test a vacation before you buy it, there are plenty of sources of information to help you make an informed decision. In vacations, as with manufacturer marketing material, buyers no longer have to rely on the glossy brochure.

Secondly, Micro Focus products improve the user experience of z/OS applications in days, rather than months. They will make users more efficient, or to enable fast mainframe application access from devices – such as iPads – to help satisfy business demand for ‘disruptive innovation’. In vacation terms, it is all about making your experience of a shared journey that bit better. You may be on the same plane, but one of you is sitting in business class.


Micro Focus application deployment enables customers to redistribute production systems wherever the business needs them. Workload can be optimized and redistributed onto other zEnterprise partitions or alternative servers, for a ‘fit for purpose’ result. Other clients have cloned applications for deployment in different business units or territories, thereby controlling operating costs and providing unrivalled flexibility.

In vacation planning terms it is like deciding to get a taxi to the hotel rather than negotiate the local transport infrastructure. The right decision upstream delivers extra flexibility downstream – now you’re here sooner than the other people on the plane, what’s it to be? Champagne or a cocktail?

Each step can be done individually, or combined for real business impact – it’s up to you. Just like planning a vacation, you don’t have to do it all in one go. But, planning it properly is part of the journey, and the next stage should always be something to look forward to. But remember – the destination is really where you want to be. That’s when the vacation starts and life gets a little easier.

Enjoy your journey

 For a sunnier vacation, click here.

For more journeys, click here.

[1] Million Instructions Per Second.

Keep up with CORBA

The first of an on-going series of updates on the CORBA product portfolio. Stay abreast of new features and find out what we have in store for the future.

This is the first of an on-going series of updates on the CORBA product portfolio. Stay abreast of new features and find out what we have in store for the future.

It’s just over 4 months since CORBA left Progress Software for the sunny realms of Micro Focus. During this time, we have been busy creating a worldwide centre of excellence with some of the world’s leading CORBA specialists. By putting our heads together, we’re able to provide solutions that not only meet evolving integration needs, but enable on-going success and confidence.

Success story
In a recent customer story, eCube Systems wanted a faster, more responsive ORB which could support its C++ development needs as well as Java. By using CORBA, application responsiveness was greatly enhanced, while adding intelligence and resilience to the system. eCube Systems wanted to “…solve business problems, not work on the plumbing,” explains Peter Marquez, Senior Partner, Sales and Marketing, eCube Systems.

Find out how CORBA enabled eCube Systems to ‘keep the lights on’ and innovate here.

FAQ – for you
Since the Artix, Orbacus and Orbix product lines joined Micro Focus, we have received questions regarding future plans and direction. We have compiled these into an FAQ, which can be seen here. As new questions crop up, these will be added to the FAQ resource. So keep a look out for updates via this blog.

If the FAQ doesn’t answer all your questions or if you have any comments, contact your local Micro Focus representative or email

Watch this space for further updates……….

A Living Legacy: RBS, A Year Later

The RBS system failure affected over 16M customers for over 3 days, during which time they could not access their funds. Derek Britton rakes over the coals and gives his perspective a year on……….


In the last few weeks we’ve seen a flurry of discussions surrounding the June 2012 RBS System Crash, published to coincide with the anniversary of the mainframe outage. The system failure affected over 16M customers for over 3 days, during which time they could not access their funds. This blog looks back at the innocuous human error, somewhere in the mainframe operations department of RBS’s IT division, which spiralled totally out of control, and asks what have we learnt.

A colourful and comprehensive perspective by Industry Publication “The Register” (“RBS Chernobyl, One Year On”, here) provides an excellent account of the results of the crash. The article talks about the “fallout” of this crisis still being felt, in particular both the subsequent regulatory scrutiny in the financial services industry, and actions taken by financial services organizations themselves to improve their own technical infrastructure.

The Compliance Lesson

It is no surprise that regulatory scrutiny increased as a direct result of the RBS debacle. In October 2012, citing a variety of high-profile causes including Libor rigging, PPI mis-selling, system crashes, The Telegraph’s Banking Correspondent Harry Wilson mentioned that the regulatory authorities had “no shortage of excuses to launch … [a] clampdown”[1] on financial services organizations.

More recently, the UK Parliamentary Commission into Banking Standards report highlighted a wide range of required changes (mandatory Chief Risk Officer role for all FS organizations, Payment Systems regulation, Account Portability investigation, Criminal Charges for reckless behaviour among others, but was criticised by others (“Reforms Failing to Address Tech Frailty”, here) for not going far enough to deal with the underlying IT infrastructure problems. Trade body “Intellect” called for greater transparency of “existing systems and processes” to help “risks be identified before they impact customers”, and a “greater number of technology-literate individuals in decision-making board positions”.

The prospect of even further regulation is now in the public domain. Jessica Twentyman of The Register described on 25th June the “palpable concern” many Financial Services sector CIOs have that the “eyes of regulators” would settle on the “back office resilience [of] …decades-old technology” (“Regulators Prepare to Probe Aging Mainframes”, here).

What remains clear is that the FCA and its various global counterparts will continue to shine a searchlight on the banking sector for as long as the industry’s various problems remain.

The Legacy Investment Lesson

So what were these “aging” systems that crashed in RBS? Reports at the time pinpointed the error to scheduling software in the RBS IBM Mainframe-based business system. While a detailed review of the cause showed human error to be the root cause, the age, complexity and suitability of those systems has also come under scrutiny.

IT industry commentator, James Governor, blogged on the topic (“Invest in Legacy, Invest in the Mainframe”, here), arguing that a well-maintained and appropriately funded “legacy” environment should and would not befall the same fate as the RBS system in June 2012.

The notion that legacy IT is fundamentally a bad thing is too simplistic a view. A well-cared-for core system will continue to provide business value that far outweighs the cost and risk of replacing it.  Moreover, age is not a sensible indicator of value. Just think of recent technology trends that have disappeared as quickly as they arrived – clearly not everything new is better. Micro Focus discussed the issue of the bad reputation of “IT legacy”, and how it is often misrepresented and erroneous, in a recent blog series. Our view was that a more a balanced view needs to be taken, and that in many cases the systems being referred to are better described as “legendary”, and can continue to provide vital business value in the future.

Investing to improve the operational efficiency of IT (and therefore the business) is the right driver, which means making investments in existing systems as well as any newer innovations. In fact, seeking to manage existing IT workload more efficiently negates many concerns about so-called legacy by removing needless costs, improving core system quality and mitigating the risk of failure. New technology standards like Eclipse and zEnterprise enable tried-and-trusted mainframe applications to serve the new demands of today’s market more efficiently.

In July 2012, RBS CEO Stephen Hester admitted in an interview in The Guardian that the major IT glitch could have been avoided if the bank had focused more on keeping its existing systems up-to-date[2]. Put even more simply, if you invest properly in legacy, it isn’t legacy, it is your current and future business.

It Could Happen Anywhere

RBS bore the brunt of public outcry at the time and the brand remains damaged from this episode. However, the rest of the banking sector has seen other examples. Since the RBS outage, there have been at least two more attributed to IT problems: over 20 million customers of Lloyds Banking Group  (including Halifax and Bank of Scotland) were locked out of their accounts in October 2012. Over 2 million customers of Co-op Bank were also blocked from their accounts. Meanwhile, technical issues in December 2011 caused a variety of customer account access problems at Commonwealth Bank Australia.

The overall health of the IT infrastructure across the industry is under scrutiny, and with each negative headline, that scrutiny intensifies.

Making Good

Among the various plans organizations already have to rectify the situation, finding a way to improve efficiency and reduce complexity without introducing further risk of failure is critical. Wholesale replacement projects are so risky, however, that ways of revamping what is already there must be considered.

By enabling organizations to modernize existing systems that support the business, and supporting a step-change in how they are planned, built and delivered, Micro Focus is helping organizations with large mainframe estates revamp valuable IT investment without risk. This provides the springboard these organizations need towards a resilient and flexible technology blueprint in the future. Our recent Enterprise blog series (here) outlines the ways Micro Focus can help zEnterprise customers. For more information, see

[1] Harry Wilson, Daily Telegraph 8th October (“Bleak Future for the Banks of Tomorrow”)