OK, so when IBM briefed me a few weeks ago on the new announcement about PHP support for CICS, I almost fell off my chair. IBM asked me what I thought and I said I was horrified…taking something as reliable and trustworthy as CICS and throwing it into the wild, unkempt PHP world just left me filled with dread. But on hearing more, my concerns were largely put to rest, and my message to others with the same initial reaction as me is ‘Don’t Panic’.

The initial description to me was ‘adding PHP support for CICS transactions’. Now I am not so old that I do not understand the power of PHP, and its ability to quickly generate nice, modern interfaces for websites and the like. But my own experience of PHP is playing games on the Internet (“Sorry the server has crashed, the damn PHP code has gone pear-shaped again”)  and messing about building pages and making a mess of them. I therefore initially viewed the idea of PHP in CICS as a great way to take reliable applications and make them unreliable/unpredictable, while probably crashing the rest of the innocent CICS apps at the same time.

However, it turns out IBM is not stupid. The biggest point that relieved my fears is that the PHP support is provided in its own address space. Now, CICS is REALLY good at protecting different address spaces from hurting each other – in fact I was part of the team that delivered the multi-region operations (MRO) capabilities to I can vouch personally that this is the case.  So all of a sudden, what had me running screaming for the hills begins to sound like something quite exciting and yet also non-threatening. As I thought about it more (and talked to some people half my age who are PHP fans and really understand the sorts of things it can do) I began to realize how smart IBM has been here. This is a great way to provide a more flexible and rapid way to build jazzy front ends to CICS apps, extending their life sustantially. It also offers the modern wave of technical people an environment with which they are initmately familiar.

The upshot is, PHP support for CICS looks like a winner. There is no need to panic about disruption to operations, because of IBM’s smart thinking in isolating the PHP functionality, but on the other hand this support offers companies a way to leverage their CICS investments, keep the technology vital and alive, respond far more quickly to the need for more attractive interfaces enabling more efective multi-channel delivery and get the kids excited and contributing.

Linux v z/OS on IBM mainframes

Five or ten years ago, this sort of question would have been unthinkable, but now mainframe users are increasingly facing a choice between whether to use Linux on System z or z/OS to host new mainframe workloads.

These new workloads may be the result of a consolidation project, or simply taking advantage of flexible architectures like SOA to utilize spare mainframe capacity, but the decision is not an obvious one in either case.

On the one hand, long-time mainframe guys will say that z/OS has grown up with the mainframe and therefore must be the best choice. But IBM has done a lot to its version of Linux for the mainframe, and Linux bigots will be quick to point out that the license costs will be cheaper and there are strong advantages in standardizing on a portable and flexible operating system enterprise-wide. Worst of all, given the polarized nature of IT in general, the decision makers find it hard to get unbiased advice on such a divisive question.

In the end, the answer to the question of whether z/OS or Linux on System z is better is not surprising – “it depends”. This subject is discussed in much more detail in a free Lustratus report, “Choosing the right SOA platform on IBM System z”, available from the Lustratus web store. While this paper focuses particularly on developing or moving SOA workloads onto System z, the analysis applies to any new mainframe workload. Summarizing the arguments in the paper, the major differences that affect the decision are that Linux is designed to offer a common environment across many platforms, and is thus less attuned to individual platform capabilities by definition, and that whereas Linux has been designed for the ‘server’ model where it is used to operating one type of workload, z/OS has been built to handle multiple subsystems from the start.

The common environment aspect of Linux offers flexibility, helps to drive license costs down and leverages widely available skills. The multi-system capabilities of z/OS combined with its close linkage to the System z platform offer the greatest exploitation of System z facilities. But as always the devil is in the details.