Norfolk Tech Journal | Putting Norfolk on the Technology Map

Home

About Us

Events

Advertise

Contact

Download Magazine

Kelvin Hoggett-Thompson

So, new technology is great, we all love it, it’s the future – or so we are led to believe. But, if you have a large IT landscape, even in big forward thinking organisations such as Aviva, the mainframe lives on and underpins all the exciting new whizzy stuff!! So why is the mainframe so good at being the bed rock of everything else? Reliable, resilient, scalable, cheap…. yes…. really…..

It may be cheaper (that’s still debatable, depending on who you talk to and what the integration points are) to build some nice brand spanking new system on the latest whizzy server technology with some software with a name that I’ve never heard of and sounds like it’s come from the clouds (pardon the pun), it might even work well most of the time.

But…. You want to extend it? That’ll be another server you’ll need. You want to make it more reliable? That’ll be a few more servers. You want lots of connectivity? More boxes. More bits. More moving parts. More things that can go wrong/break. And are those skills in the market place when you want to think about going global?

Hmm…. Costs are starting to ramp up a bit now. Your cheap and cheerful little server implementation is now a whole farmyard full of servers. How’s that cost benefit case looking now? Where’s the failover – oh yes, right, of course, that’s next door’s farmyard and they can only get to each other by one gate….which is rusty and has a habit of breaking…..

So the longer term costs and complexities are starting to far out weigh any short-term cost savings of your cheap as chips (sorry, another pun) original system.

Did you know that the big blue chip company across the water (IBM) apparently sold more IMS licenses last year than it did in the previous forty years. They (like all us old dinosaurs) know the benefits of the mainframe and are investing it.

Did you know that anything on the Mainframe can service web browser requests? CICS and IMS both have in-built capability of enabling web-connectivity. That’s right, straight from a web-page into the mainframe. You can even have code sitting on the mainframe serving up nice shiny web-pages. Bet you didn’t know that! Who said it was all green-screen with old dinosaurs looking after it…oh wait…..the dinosaur might be right.

Now do you see the benefits? Huge numbers of transactional throughput plus a browser, all on one reliable, resilient, scalable platform.

So the answer really is mainframe….now, what was the question again?

Words: Kelvin Hoggett-Thompson

Nic Powers October 8, 2013 at 11:49 am Nice one Kelvin – I wonder if any of the young upstarts will take up the challenge! Reply ↓

Nice one Kelvin – I wonder if any of the young upstarts will take up the challenge!

pjgrenyer Post author October 8, 2013 at 5:11 pm This young upstart is not convinced by the argument (although this is an excellent piece) and I am in the process of commissioning the counter argument. Watch this space. Reply ↓

This young upstart is not convinced by the argument (although this is an excellent piece) and I am in the process of commissioning the counter argument. Watch this space.

Abhishek Sinha October 9, 2013 at 6:02 am Excellent write-up Kelvin. Just to add to this, mainframe is not behind even in mobile technologies. Mobile applications can now be connected directly with CICS TS through JSON web services. Whatever latest is in technology, mainframe has already got it – so the answer really is ‘mainframes’. Reply ↓

Excellent write-up Kelvin. Just to add to this, mainframe is not behind even in mobile technologies. Mobile applications can now be connected directly with CICS TS through JSON web services. Whatever latest is in technology, mainframe has already got it – so the answer really is ‘mainframes’.

Colin Mower October 10, 2013 at 7:52 am Great article, Kelvin, and yes it is amazing just how modern and capable the Mainframe is as an Enterprise server, and in many aspects is still a long way ahead of any other server – particularly in terms of running a mixed variety of workloads with its mature virtualisation. Maybe it is the name ‘Mainframe’ that immediately makes people think of a massive water cooled beast with large tape drives and green screen terminals. Ok, so it was designed and built in the 1960′s, but so was the Boeing 747 – do people think that still uses 60′s technology?! The 747 is still the most efficient, reliable and cheapest way to carry large amounts of passengers across the Atlantic, yet has all the modern avionics. You certainly wouldn’t replace it with a vast fleet of new 4 seat Cessnas, that needed more fuel, more pilots, more maintenance crew and took longer to reach the destination, just because the 747 is “old”. So will the Mainframe carry on using green screens? Yes, probably – it’s still the fastest way to interact with the system, just as terminal windows into Linux and Unix are. Will there be more GUI development and management tools? Absolutely – IBM and the other software vendors are investing huge amounts in continuing to develop these interfaces into the Mainframe, which help improve development cycles and make it more accessible for users. Has the Mainframe got a place in 21st century computing? Of course: whether it is running hundreds or thousands of Linux images cheaply in a private Cloud, analysing the huge amounts of ‘big data’, running mobile apps or integrating mobile into existing apps, or simply serving millions of concurrent transactions with data – or all of the above at once – the Mainframe does it all with ease. Does this come at a price? Yes…a cheap one when you look at all the economics! Oh, and one last point on the young upstarts – last year alone, 826 UK students took part in IBM’s global Mainframe challenge – and the UEA came top in terms of the number coming 1st, 2nd and 3rd. See http://ibm.biz/BdxGFW Reply ↓ pjgrenyer Post author October 10, 2013 at 8:25 am All, I’m sorry. I’m just not buying this at all. PC based virtualisation can do all of this and I suspect is significantly cheaper and is significantly easier to add hardware too when it needs to be expanded. And why would you run mobile apps on anything other than a mobile device (including tablets obviously). I don’t hear a lot about 4th generation languages on Mainframes. It’s always some exotic language or runtime I’ve never heard of before. However, I’m no expert in either. It would be good to see a comparison in total cost of ownership. As far as I know, no one is providing cloud based virtual mainframe hosting. I’ve invited Nic and Kelvin to come and have a debate at norfolkdevelopers.com. So far they’re playing hard to get. Would anyone else be up for it? This is intended to be a serious debate, not a bun fight and would have industry experts on both sides. Reply ↓

Great article, Kelvin, and yes it is amazing just how modern and capable the Mainframe is as an Enterprise server, and in many aspects is still a long way ahead of any other server – particularly in terms of running a mixed variety of workloads with its mature virtualisation.

Maybe it is the name ‘Mainframe’ that immediately makes people think of a massive water cooled beast with large tape drives and green screen terminals. Ok, so it was designed and built in the 1960′s, but so was the Boeing 747 – do people think that still uses 60′s technology?! The 747 is still the most efficient, reliable and cheapest way to carry large amounts of passengers across the Atlantic, yet has all the modern avionics. You certainly wouldn’t replace it with a vast fleet of new 4 seat Cessnas, that needed more fuel, more pilots, more maintenance crew and took longer to reach the destination, just because the 747 is “old”.

So will the Mainframe carry on using green screens? Yes, probably – it’s still the fastest way to interact with the system, just as terminal windows into Linux and Unix are.

Will there be more GUI development and management tools? Absolutely – IBM and the other software vendors are investing huge amounts in continuing to develop these interfaces into the Mainframe, which help improve development cycles and make it more accessible for users.

Has the Mainframe got a place in 21st century computing? Of course: whether it is running hundreds or thousands of Linux images cheaply in a private Cloud, analysing the huge amounts of ‘big data’, running mobile apps or integrating mobile into existing apps, or simply serving millions of concurrent transactions with data – or all of the above at once – the Mainframe does it all with ease. Does this come at a price? Yes…a cheap one when you look at all the economics!

Oh, and one last point on the young upstarts – last year alone, 826 UK students took part in IBM’s global Mainframe challenge – and the UEA came top in terms of the number coming 1st, 2nd and 3rd. See http://ibm.biz/BdxGFW

pjgrenyer Post author October 10, 2013 at 8:25 am All, I’m sorry. I’m just not buying this at all. PC based virtualisation can do all of this and I suspect is significantly cheaper and is significantly easier to add hardware too when it needs to be expanded. And why would you run mobile apps on anything other than a mobile device (including tablets obviously). I don’t hear a lot about 4th generation languages on Mainframes. It’s always some exotic language or runtime I’ve never heard of before. However, I’m no expert in either. It would be good to see a comparison in total cost of ownership. As far as I know, no one is providing cloud based virtual mainframe hosting. I’ve invited Nic and Kelvin to come and have a debate at norfolkdevelopers.com. So far they’re playing hard to get. Would anyone else be up for it? This is intended to be a serious debate, not a bun fight and would have industry experts on both sides. Reply ↓

All, I’m sorry. I’m just not buying this at all.

PC based virtualisation can do all of this and I suspect is significantly cheaper and is significantly easier to add hardware too when it needs to be expanded. And why would you run mobile apps on anything other than a mobile device (including tablets obviously).

I don’t hear a lot about 4th generation languages on Mainframes. It’s always some exotic language or runtime I’ve never heard of before.

However, I’m no expert in either. It would be good to see a comparison in total cost of ownership. As far as I know, no one is providing cloud based virtual mainframe hosting.

I’ve invited Nic and Kelvin to come and have a debate at norfolkdevelopers.com. So far they’re playing hard to get. Would anyone else be up for it? This is intended to be a serious debate, not a bun fight and would have industry experts on both sides.

Colin Mower October 10, 2013 at 4:04 pm I’m always willing to have a good debate about the Mainframe, and as with all these things it can sometimes get emotional, but I always stick to the facts I’ve worked on all platforms and try to remain unbiased, as the Mainframe certainly isn’t right for everything! Just to comment on your points raised: 1) Virtualisation – yes you’re absolutely right that all the virtualisation technologies are much of a muchness these days, but the difference with the Mainframe is that it has 30 years of development under its belt. For example, you can run mixed workloads at 100% CPU utilisation 24 hours a day, and you don’t need separate tin to separate production with non-production – the hypervisor will ensure all happily co-exist on one box and share resources nicely. 2) Mobile apps – it depends whether it’s a native, hybrid or web based mobile app…even native apps may still need to connect through to other systems, and you need a server or gateway for that. If it’s a web app, you could run directly from the Mainframe in HTML5, for example. 3) You can run pretty much any language on there – Java, C, C++, scripting languages. It’s just that COBOL still remains the most common. 4) TCO’s aren’t the easiest of things to do as you have to pick apart everything – power, floor space, operational run costs….the list goes on….it’s something IBM does though. There is a good comparison of Linux running on different environments including the Mainframe which is available soon, if not already. Reply ↓ pjgrenyer Post author October 10, 2013 at 4:10 pm Colin, that’s good to hear! I’ll see if I can track down someone from VMWare or similar for the other side of the argument. Are you ok with coming to Norwich sometime for this? Reply ↓ Colin Mower October 10, 2013 at 5:17 pm Yes of course – I live in Norwich so no problems. Reply ↓ Martin Payne October 13, 2013 at 11:32 am While I agree with this, ISTM Aviva’s management see mainframe as a legacy millstone that they’d drop completely if they could. I wonder if @cioinsurance would come to talk about that? cheers, Martin Reply ↓ pjgrenyer Post author October 13, 2013 at 3:49 pm Martin, I think you should ask him! Reply ↓

I’m always willing to have a good debate about the Mainframe, and as with all these things it can sometimes get emotional, but I always stick to the facts I’ve worked on all platforms and try to remain unbiased, as the Mainframe certainly isn’t right for everything!

Just to comment on your points raised: 1) Virtualisation – yes you’re absolutely right that all the virtualisation technologies are much of a muchness these days, but the difference with the Mainframe is that it has 30 years of development under its belt. For example, you can run mixed workloads at 100% CPU utilisation 24 hours a day, and you don’t need separate tin to separate production with non-production – the hypervisor will ensure all happily co-exist on one box and share resources nicely.

2) Mobile apps – it depends whether it’s a native, hybrid or web based mobile app…even native apps may still need to connect through to other systems, and you need a server or gateway for that. If it’s a web app, you could run directly from the Mainframe in HTML5, for example.

3) You can run pretty much any language on there – Java, C, C++, scripting languages. It’s just that COBOL still remains the most common.

4) TCO’s aren’t the easiest of things to do as you have to pick apart everything – power, floor space, operational run costs….the list goes on….it’s something IBM does though. There is a good comparison of Linux running on different environments including the Mainframe which is available soon, if not already.

pjgrenyer Post author October 10, 2013 at 4:10 pm Colin, that’s good to hear! I’ll see if I can track down someone from VMWare or similar for the other side of the argument. Are you ok with coming to Norwich sometime for this? Reply ↓ Colin Mower October 10, 2013 at 5:17 pm Yes of course – I live in Norwich so no problems. Reply ↓

Colin, that’s good to hear! I’ll see if I can track down someone from VMWare or similar for the other side of the argument. Are you ok with coming to Norwich sometime for this?

Colin Mower October 10, 2013 at 5:17 pm Yes of course – I live in Norwich so no problems. Reply ↓

Yes of course – I live in Norwich so no problems.

Martin Payne October 13, 2013 at 11:32 am While I agree with this, ISTM Aviva’s management see mainframe as a legacy millstone that they’d drop completely if they could. I wonder if @cioinsurance would come to talk about that? cheers, Martin Reply ↓ pjgrenyer Post author October 13, 2013 at 3:49 pm Martin, I think you should ask him! Reply ↓

While I agree with this, ISTM Aviva’s management see mainframe as a legacy millstone that they’d drop completely if they could.

I wonder if @cioinsurance would come to talk about that?

cheers, Martin

pjgrenyer Post author October 13, 2013 at 3:49 pm Martin, I think you should ask him! Reply ↓

Martin, I think you should ask him!

Gary Howell October 11, 2013 at 3:45 pm As mainframers, all we ever ask is that the mainframe is compared to alternative solutions on a level playing field. There are so many variables involved in conducting TCO and TCA type studies, that it is impossible to get a definitive answer and it is easy to skew the figures to suit your preferred answer. The biggest issue that the mainframe has, is it’s perception in the market place. It is still deemed to be old and costly but there are rarely many facts used to back this up. I often see smaller applications, that compare themselves to the whole cost of a mainframe when it would only utilise a small proportion. These applications should not be treated in isolation as most businesses run a variety of different applications. As Kelvin mentioned, server sprawl can be a big problem for some customers and the mainframe ‘could’ be the answer. It is not the answer to everything but it is an answer that is too often overlooked, based on misconceptions. Reply ↓ pjgrenyer Post author October 11, 2013 at 3:47 pm Gary, so is the answer to find a solution that can be implemented on both and look at the TOC and other considerations? Reply ↓ Gary Howell October 11, 2013 at 5:40 pm Absolutely not, if I understand you correctly. My point is, to define what is the correct solution, you have to be able to fairly judge all of the available options. A big part of this is to know your starting point and your end goal, which is what Enterprise Architecture is all about. TOGAF did leave an impression with me ! Solutions should not be considered in total isolation. I don’t believe there is an easy answer, but having a clearly defined Enterprise Architecture helps you to make the correct decisions along the way. In an ideal world there would be no restrictions. You could start off by defining your current environment and strategy and then when new business problem came along, you would be able to consider all options, before selecting your solution. Unfortunately we live in the real world and there are many outside influences on whatever processes we follow. So mainframe is the answer now what’s the question is not a valid statement as isn’t Intel is the answer now what’s the question. Reply ↓

As mainframers, all we ever ask is that the mainframe is compared to alternative solutions on a level playing field. There are so many variables involved in conducting TCO and TCA type studies, that it is impossible to get a definitive answer and it is easy to skew the figures to suit your preferred answer. The biggest issue that the mainframe has, is it’s perception in the market place. It is still deemed to be old and costly but there are rarely many facts used to back this up. I often see smaller applications, that compare themselves to the whole cost of a mainframe when it would only utilise a small proportion. These applications should not be treated in isolation as most businesses run a variety of different applications. As Kelvin mentioned, server sprawl can be a big problem for some customers and the mainframe ‘could’ be the answer. It is not the answer to everything but it is an answer that is too often overlooked, based on misconceptions.

pjgrenyer Post author October 11, 2013 at 3:47 pm Gary, so is the answer to find a solution that can be implemented on both and look at the TOC and other considerations? Reply ↓ Gary Howell October 11, 2013 at 5:40 pm Absolutely not, if I understand you correctly. My point is, to define what is the correct solution, you have to be able to fairly judge all of the available options. A big part of this is to know your starting point and your end goal, which is what Enterprise Architecture is all about. TOGAF did leave an impression with me ! Solutions should not be considered in total isolation. I don’t believe there is an easy answer, but having a clearly defined Enterprise Architecture helps you to make the correct decisions along the way. In an ideal world there would be no restrictions. You could start off by defining your current environment and strategy and then when new business problem came along, you would be able to consider all options, before selecting your solution. Unfortunately we live in the real world and there are many outside influences on whatever processes we follow. So mainframe is the answer now what’s the question is not a valid statement as isn’t Intel is the answer now what’s the question. Reply ↓

Gary, so is the answer to find a solution that can be implemented on both and look at the TOC and other considerations?

Gary Howell October 11, 2013 at 5:40 pm Absolutely not, if I understand you correctly. My point is, to define what is the correct solution, you have to be able to fairly judge all of the available options. A big part of this is to know your starting point and your end goal, which is what Enterprise Architecture is all about. TOGAF did leave an impression with me ! Solutions should not be considered in total isolation. I don’t believe there is an easy answer, but having a clearly defined Enterprise Architecture helps you to make the correct decisions along the way. In an ideal world there would be no restrictions. You could start off by defining your current environment and strategy and then when new business problem came along, you would be able to consider all options, before selecting your solution. Unfortunately we live in the real world and there are many outside influences on whatever processes we follow. So mainframe is the answer now what’s the question is not a valid statement as isn’t Intel is the answer now what’s the question. Reply ↓

Absolutely not, if I understand you correctly. My point is, to define what is the correct solution, you have to be able to fairly judge all of the available options. A big part of this is to know your starting point and your end goal, which is what Enterprise Architecture is all about. TOGAF did leave an impression with me ! Solutions should not be considered in total isolation. I don’t believe there is an easy answer, but having a clearly defined Enterprise Architecture helps you to make the correct decisions along the way. In an ideal world there would be no restrictions. You could start off by defining your current environment and strategy and then when new business problem came along, you would be able to consider all options, before selecting your solution. Unfortunately we live in the real world and there are many outside influences on whatever processes we follow. So mainframe is the answer now what’s the question is not a valid statement as isn’t Intel is the answer now what’s the question.

Dom Davis October 12, 2013 at 12:19 am I always remember a presentation given to me at UBS by Sun (remember them?) about the latest and greatest version of Solaris and the new iron they had to power it. After the glitzy slides and slick sales pitch there was a silence in the room followed by one of our mainframe guys who simply said “so you’re finally bringing you OS into the 1970s!” Given this was 2004 the Sun guys were a little upset by this comment. After a long debate they had to concede that the only “new” feature they were bringing to the party that the mainframes didn’t have was a fancy GUI. Reply ↓

I always remember a presentation given to me at UBS by Sun (remember them?) about the latest and greatest version of Solaris and the new iron they had to power it. After the glitzy slides and slick sales pitch there was a silence in the room followed by one of our mainframe guys who simply said “so you’re finally bringing you OS into the 1970s!”

Given this was 2004 the Sun guys were a little upset by this comment. After a long debate they had to concede that the only “new” feature they were bringing to the party that the mainframes didn’t have was a fancy GUI.

Paul Russell October 13, 2013 at 9:10 am Something I find fascinating about this is that I think for the first time it might actually be nearly as easy to build a web app on the mainframe as any other kind of app. I was just thinking about my own experience in building web apps these days, and more and more of the server side code I write is largely concerned with exposing JSON APIs, which are then consumed by JavaScript running in the browser. There’s no component state to manage, no heavy duty OO required. I still think though that the mainframe’s biggest problem is that so much code running there is written in cobol, which makes writing tight, reusable, modular code so difficult. So I still think using something like Java on the platform would be a better choice for a web application if only to be able to modularise applications and have access to a stack ! I think there is a bit of FUD about mainframes. I’ve seen inside one. The actual compute element of it was about 1.5x times the size of a washing machine. Not huge. Almost certainly smaller than an equivalent set of compute power in racks I would say. Most of the rest of the box was empty space holding a think pad (this was a few years ago before IBM sold to Lenovo) and then a slug of air conditioner at the top. Of course this whole thing was wrapped in a big ostentatious box like something out of a sci-fi movie, but this was more marketing than engineering. Reply ↓ Martin Payne October 13, 2013 at 12:00 pm Re machine size – this is an inevitable consequence of the laws of physics (speed of light). Back in the day, speeds were dominated by transistor switching, and a mainframe processor was an array of hundreds of bipolar chips clocked to the max and water-cooled. Now, AFAIK, the CPUs are custom PowerPC microprocessors – running CMOS like everyone else so they don’t vapourise. At 1 gigahertz, an electrical signal can only travel a foot in one clock cycle (1ns) – thus the compact size. The mainframe’s real power is in I/O & database throughput, not monster CPU performance (and, I suspect, low latency comms between back-end components of the architecture that would be on separate servers in a high-volume PC environment). cheers, Martin Reply ↓

Something I find fascinating about this is that I think for the first time it might actually be nearly as easy to build a web app on the mainframe as any other kind of app.

I was just thinking about my own experience in building web apps these days, and more and more of the server side code I write is largely concerned with exposing JSON APIs, which are then consumed by JavaScript running in the browser. There’s no component state to manage, no heavy duty OO required.

I still think though that the mainframe’s biggest problem is that so much code running there is written in cobol, which makes writing tight, reusable, modular code so difficult.

So I still think using something like Java on the platform would be a better choice for a web application if only to be able to modularise applications and have access to a stack !

I think there is a bit of FUD about mainframes. I’ve seen inside one. The actual compute element of it was about 1.5x times the size of a washing machine. Not huge. Almost certainly smaller than an equivalent set of compute power in racks I would say. Most of the rest of the box was empty space holding a think pad (this was a few years ago before IBM sold to Lenovo) and then a slug of air conditioner at the top. Of course this whole thing was wrapped in a big ostentatious box like something out of a sci-fi movie, but this was more marketing than engineering.

Martin Payne October 13, 2013 at 12:00 pm Re machine size – this is an inevitable consequence of the laws of physics (speed of light). Back in the day, speeds were dominated by transistor switching, and a mainframe processor was an array of hundreds of bipolar chips clocked to the max and water-cooled. Now, AFAIK, the CPUs are custom PowerPC microprocessors – running CMOS like everyone else so they don’t vapourise. At 1 gigahertz, an electrical signal can only travel a foot in one clock cycle (1ns) – thus the compact size. The mainframe’s real power is in I/O & database throughput, not monster CPU performance (and, I suspect, low latency comms between back-end components of the architecture that would be on separate servers in a high-volume PC environment). cheers, Martin Reply ↓

Re machine size – this is an inevitable consequence of the laws of physics (speed of light). Back in the day, speeds were dominated by transistor switching, and a mainframe processor was an array of hundreds of bipolar chips clocked to the max and water-cooled.

Now, AFAIK, the CPUs are custom PowerPC microprocessors – running CMOS like everyone else so they don’t vapourise. At 1 gigahertz, an electrical signal can only travel a foot in one clock cycle (1ns) – thus the compact size.

The mainframe’s real power is in I/O & database throughput, not monster CPU performance (and, I suspect, low latency comms between back-end components of the architecture that would be on separate servers in a high-volume PC environment).

Fraser GOFFIN October 13, 2013 at 1:43 pm If you want to make a TCO case for mainframe and compare apples with apples, then you really should factor in the sunk costs to build and equip the massive infrastructure spend on the dual day centres with a bomb proof mound in between. You might also want to mention what cost is involved when the time comes to add or upgrade mainframe processor capability. No one in alternative cloud based solutions needs to worry about that kind of upfront investment these days. It’s cloud that will also provide the resilience and failover characteristics where that is needed and enable to to flex performance, scale, availability and many other non-functionals at will and at low cost. As far as availability is concerned, ever tried asking whether mainframe apps are available 24×7. If you have you will probably remember the ‘.. Oh no, extended office hours only’ response, oh, and ‘.. we also need to allow for IPL downtime’ (aka: Ctrl-Alt-Del) ! Reply ↓ Martin Payne October 13, 2013 at 3:19 pm > If you want to make a TCO case for mainframe and compare apples with apples, > then you really should factor in the sunk costs to build and equip the massive > infrastructure spend on the dual day centres with a bomb proof mound in between. “Day centres”? Don’t think that was called for! Also, if the system being hosted is truly mission-critical, I suspect it will be multi-site hosted (or at least fail-over) whether mainframe or PC, even if the PC datacentres are run by Amazon, or whoever. And mainframe datacentres don’t have to be next door to each other to be kept in sync. cheers, Martin Reply ↓ pjgrenyer Post author October 13, 2013 at 3:50 pm Fraser, would you like to write a follow-up article giving the other side? Reply ↓

If you want to make a TCO case for mainframe and compare apples with apples, then you really should factor in the sunk costs to build and equip the massive infrastructure spend on the dual day centres with a bomb proof mound in between.

You might also want to mention what cost is involved when the time comes to add or upgrade mainframe processor capability.

No one in alternative cloud based solutions needs to worry about that kind of upfront investment these days. It’s cloud that will also provide the resilience and failover characteristics where that is needed and enable to to flex performance, scale, availability and many other non-functionals at will and at low cost.

As far as availability is concerned, ever tried asking whether mainframe apps are available 24×7. If you have you will probably remember the ‘.. Oh no, extended office hours only’ response, oh, and ‘.. we also need to allow for IPL downtime’ (aka: Ctrl-Alt-Del) !

Martin Payne October 13, 2013 at 3:19 pm > If you want to make a TCO case for mainframe and compare apples with apples, > then you really should factor in the sunk costs to build and equip the massive > infrastructure spend on the dual day centres with a bomb proof mound in between. “Day centres”? Don’t think that was called for! Also, if the system being hosted is truly mission-critical, I suspect it will be multi-site hosted (or at least fail-over) whether mainframe or PC, even if the PC datacentres are run by Amazon, or whoever. And mainframe datacentres don’t have to be next door to each other to be kept in sync. cheers, Martin Reply ↓

> If you want to make a TCO case for mainframe and compare apples with apples, > then you really should factor in the sunk costs to build and equip the massive > infrastructure spend on the dual day centres with a bomb proof mound in between.

“Day centres”? Don’t think that was called for!

Also, if the system being hosted is truly mission-critical, I suspect it will be multi-site hosted (or at least fail-over) whether mainframe or PC, even if the PC datacentres are run by Amazon, or whoever. And mainframe datacentres don’t have to be next door to each other to be kept in sync.

pjgrenyer Post author October 13, 2013 at 3:50 pm Fraser, would you like to write a follow-up article giving the other side? Reply ↓

Fraser, would you like to write a follow-up article giving the other side?

Fraser GOFFIN October 13, 2013 at 1:50 pm > Did you know that anything on the Mainframe can service web browser > requests? … That’s right, straight from a web-page into the mainframe. You > can even have code sitting on the mainframe serving up nice shiny web- > pages. Bet you didn’t know that! Well, most of us who have worked in integration for the past decade are very well aware of these somewhat simplistic capabilities. Ever wonder why we don’t do that ? Reply ↓

> Did you know that anything on the Mainframe can service web browser > requests? … That’s right, straight from a web-page into the mainframe. You > can even have code sitting on the mainframe serving up nice shiny web- > pages. Bet you didn’t know that!

Well, most of us who have worked in integration for the past decade are very well aware of these somewhat simplistic capabilities. Ever wonder why we don’t do that ?

Fraser GOFFIN October 13, 2013 at 2:04 pm > I still think though that the mainframe’s biggest problem is that so much code > running there is written in cobol, which makes writing tight, reusable, modular > code so difficult. I think the problem is more to do with the APIs that applications expose rather than the language. In that respect the ESB facade model helps to an extent, but those efforts are still somewhat hamstrung by typically ‘leaky’ system level APIs and the lack of composable business functionality that was never designed to be exposed as reusable components/services. It’s true that sometime ago [at a well known major Insurance Co] there was some appetite to move mainframe COBOL development into a more ‘test driven/CI’ practice, but it never got much traction. Not sure if it was culture or tech which stopped that happening. Reply ↓

> I still think though that the mainframe’s biggest problem is that so much code > running there is written in cobol, which makes writing tight, reusable, modular > code so difficult.

I think the problem is more to do with the APIs that applications expose rather than the language. In that respect the ESB facade model helps to an extent, but those efforts are still somewhat hamstrung by typically ‘leaky’ system level APIs and the lack of composable business functionality that was never designed to be exposed as reusable components/services.

It’s true that sometime ago [at a well known major Insurance Co] there was some appetite to move mainframe COBOL development into a more ‘test driven/CI’ practice, but it never got much traction. Not sure if it was culture or tech which stopped that happening.

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

Name *

Email *

Website

Comment

Notify me of follow-up comments by email.

Notify me of new posts by email.

Sign-up to receive regular updates on all of our content and site activities.

Epos Now are recruiting.

C# Developer, up to £35K – Norwich

.NET Developer, up to £35K – Norwich

Graduate Integration Support Analyst, £20K – £25K – Norwich

Web Developer, up to £35K – Norwich

Online, from the Outset.

ASP.NET Web Developer

Problem Solvers wanted @ Yahoo

Senior Software/Web Developer

Looking for a mobile developer…

Meet the Community : Douglas Fraser

NorDevCon tickets on sale now & Winter is Coming – Part 2

NIGD: Game Club : “The Last of Us” and “GTA V”

Norwich Sound and Vision Festival: Interactive Conference

NRUG October Review: Foxes and Badgers

Meet The Community: John Fagan

NorDevCon: Winter Is Coming (Part 1)

SyncNorwich: TechCrunch Visits Norwich

Choosing an MBAAS Solution (OR NOT).

SyncNorwich: Visualising Big Data

(c) 2013 Norfolk Tech Journal