New virtual CICS user group

How many times have you come away from a conference or a presentation and thought wow, that was really useful? Perhaps one small nugget of information from the speaker has opened a door for further development of work at your site. And most technical presentations are full of gems of information – both for the novice user and those more technically experienced.

But how often have you had to fight to justify attending meetings with other professionals? How often have you struggled to build a business case showing that a particular event or conference really will pay back more than it costs in your time off work, the cost of staff to cover your absence, travel costs, subsistence allowance, and hotel fees?

Wouldn’t it be great if there was a way to attend a highly professional technically-oriented seminar or presentation without having to leave your company’s offices – without, perhaps, even having to leave your desk?

And wouldn’t it be amazing if there was a single place where you could go and find out a little bit about the latest CICS product announcements, including a link to get more information if you wanted it? How cool would it be if there was a list of tools that ran on CICS with a brief summary of what each product did? And what about some way of finding out whenever someone published a new article about using CICS in IBM Systems Magazine or zJournal, or wherever – wouldn’t that be useful?

Well, the great news is that the all-new Virtual CICS user group at www.fundi.com/virtualcics provides all that and more. On the Web site you’ll find a list of useful applications that enhance CICS, and a list of CICS service providers. You’ll also find the latest product announcements and articles.

In addition, every other month (that’s six times a year) there will be a webinar. Using Citrix GoToMeeting, you’ll be able to stay at your desk and interact with other members of the user group and listen to the latest presentation by an acknowledged CICS expert. In the months when there isn’t a webinar, there will be a newsletter sent to all members keeping them up-to-date with the latest news.

And if you’re wondering how much this kind of high-quality service is likely to cost you, the answer is nothing – not a penny! Membership of the user group is free – you just need to sign up at www.fundi.com/virtualcics/register.htm. And the webinars are completely free to members. We’ll e-mail you a link about a fortnight before the webinar with all the information you need.

So, if you’re a CICS professional, this is the user group specifically tailored for you.

Why not join right now?

You may also be interested to know that the Virtual IMS user group has been running since November 2007. You can find out more about that at www.fundi.com/virtualIMS.

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.