programmers quotes

July 4, 2010

What is fair?

Is it fair to treat all people equally? This isn’t the start of some philosophical discussion, just the starting point for this blog. So, if you agree, it’s not fair to treat all people equally (remember how the prodigal son was treated), then can it be fair to treat all organizations equally? And, if different organizations should be treated differently, who is to decide what is fair and what criteria they should use for deciding what’s fair?

Part of the answer is that these decisions are usually left to the courts. And so, Neon Enterprise Software, which is currently embroiled in a legal dispute with IBM in the US courts, is filing a complaint with the European Commission alleging “ongoing anti-competitive and abusive conduct” by IBM.

Neon originally filed a lawsuit in December 2009 accusing IBM of intimidating potential customers away from its zPrime software. zPrime, as you’ll recall, allowed businesses to run workloads on specialty processors (zIIP and zAAP) – giving money to NEON. That saved organizations running those workloads on their central processors and the associated usage charges – money that would have gone to IBM. In January, IBM filed a countersuit against Neon, suggesting an attempt to hijack IBM’s intellectual property. They suggested it was like stealing cable TV.

The European Commission is already familiar with anti-IBM cases. T3 Technologies, which was a clone mainframe distributor, has filed a complaint in Europe. And TurboHercules, with its commercial version of the open source Hercules mainframe emulator, has similarly filed a complaint. Microsoft faced the EU from about 2003 to 2009 – you may remember suddenly having a choice of browsers being made available on your PC.

So is IBM acting fairly? Are these other organizations being fair? We’ll wait and see what the courts say, but I wonder what you think?

Interestingly this week NEON offered zPrime for IMS for just 1 dollar to customers. You can find the announcement at www.neon.com/neon/news_070110_1.shtm.

On a completely different note, IBM has a new White Paper entitled “Enterprise and Web 2.0 Application Support in a Modern Mainframe Environment”. It can be found at http://images.tmcnet.com/tmc/whitepapers/documents/whitepapers/2010/2629-enterprise-web-20-application-support-from-ibm.pdf. It discusses how IBM WebSphere Portal allows mainframers to make applications available on the Web.

IBM WebSphere Portal Enable for IBM z/OS leverages z/OS resources (eg RACF and z/OS Workload Manager technology) and the White Paper discusses how to add Web-facing workloads. By using WebSphere Portal, organizations provide added value to their customers and employees while at the same time enjoying the advantages of mainframe performance, scalability, and quality of service.

June 27, 2010

Poor mainframe performance

If my new batch applications aren’t performing as well as I’d hoped, what should I do? Well, the most likely answer is go back to the original code and see what was going wrong. Another solution might be to forget all about developing mainframe-based applications all together and move to a “newer” platform. I put newer in quotes because the IBM-compatible (does anyone ever say that anymore?) PC has been around since 1981 (12th August, I’m told) – which makes it older than many of the legacy applications it’s meant to replace and older than many of the “experts” who work on it! But there’s a third alternative – one well-known to senior mainframers who still inhabit enterprise sites. I can sum it up in three letters. J, C, and L – Job Control Language.

I had it drawn to my attention by Guy Giuffre that the main causes for batch applications wasting mainframe resources such as DASD, tape, and CPU cycles is invariably poor JCL and improper job scheduling. I was assured that the majority of performance problems are “caused by programmers who may know how to write code but are completely lost in writing effective JCL or in putting together job streams that run efficiently”. And if that particular blind spot wasn’t bad enough, there was another target of attack. Mr Giuffre asserted that: “These problems are then compounded by application support analysts who either blindly install what is given to them by the programmers or who do not have the ability to dissect what is given to them and optimize it.”

Hard-hitting stuff, but where’s the evidence? Again, Guy was able to identify his own successes by confirming that he didn’t need code to be re-written, he could achieve better performance by rewriting JCL and realigning job scheduling so successfully that he achieved DASD reductions of as much as 45%, tape reductions of as much as 50%, and overnight batch application run-time reductions of as much as 40%.

There are more savings to be had for an organization. For example, it becomes possible to avoid having to man shifts over a weekend because this and scheduling optimization results in the weekend cycle finishing by 7:30am on a Saturday morning instead of 5:30pm on a Saturday evening.

If someone were to turn up for a meeting with the IT Director and offer them a product that could bring about similar savings, then I bet they would have an easy sale on their hands. And yet, many sites have experienced mainframe programmers or system support personnel like Guy Giuffre, who understand the bigger picture and are not seduced by the need to run every application from a browser using AJAX and RESTful states. They can picture what’s going on inside the mainframe and make changes to improve performance of individual applications. And because it’s their job, their skills and abilities are not always celebrated the way more fashionable successes might be.

And, with so many experienced mainframe people coming towards retirement age, this powerful ability – this sense of what needs to be done to improve performance without pouring over hundreds of line of code – may soon become lost to many organizations. So I suggest that managers start picking the brains of the mainframe staff they have to ensure that this kind of knowledge is preserved. Otherwise, their companies will need bigger and faster hardware, not because their programs are bigger or clumsier, but because no-one has taken the trouble to look at the JCL and the job scheduling. Thanks Guy, for drawing our attention to this.