Being in the mainframe business for about 10 years now, I hear interesting anecdotes from time to time, often from the most unlikely sources. I may have taken some liberty with the title, but it’s a true story, and it relates well to what I see in the mainframe business all the time.

A good friend of mine is a junior captain on one of the big cruise lines that works the typical vacation routes in the Caribbean, Barbados, Mexico and South America. He’s a young guy who loves his job, but worries about things he cannot control. He told me a story about a voyage he was on a few years earlier as first officer, serving under a very capable captain, whom he knew well.

The voyage began from Miami, heading south. The weather was beautiful with blue skies all day and a full star-scape all night. First port of call was Cancun, and they made that in great time – reaching port on time is critically important in the cruise business. Cancun is a favorite, and they left on time two days later.

The next port was George Town in Grand Cayman – again the weather was perfect with blue skies and calm waters. There were a few maintenance issues that were fixed on board overnight, but they were able to maintain their schedule, departing on time. The ship was again running well, the ocean was smooth the passengers aboard were happy.

The final port of call was Dunns River Falls resort on the northern side of Jamaica. I have never been there, but my friend tells me that it is absolutely beautiful; apparently the beach and the falls alone are worth the trip.

However, their good fortune changed somewhat the next morning – there was concern from the captain that a storm was passing to the west. It soon changed direction and intensity, and just as they were preparing to depart, the storm came closer, costing them a five hour delay in port.

Once the storm passed, they were on their way again and heading north back to Miami; the sea was calm, so it was pedal-to-the-metal, as the captain wanted to get home on time. They even turned on some additional engines to gain five extra knots, to ensure that they would make port on time.

They made it back to Miami on time; the captain was pleased and came down to congratulate the entire crew. The customers disembarked, most of the crew switched out, and the new guests started coming aboard. Sounds like a happy tale, but…

A week later, the captain received a call from the cruise line’s accounting department, and they were quite annoyed – it seems that rushing home the previous week used 50% more fuel on that journey than any other that year. The CFO at their head office was getting a little hot under the collar, and could not understand it.

This additional fuel usage had removed all profit from the month’s total cruise income; amazing that one small change had affected the financial picture for a whole month. The captain received a severe reprimand, but what could he have done differently? He could have kept at the planned cruising speed, but he would have been 5 hours late home, affecting the next cruise. Life is unfair. So what does this have to do with anything?

Well, being in the mainframe business, I’m quite familiar with how unexpected events can caused a spike in peak usage of resource consumption on the mainframe. Does a usage peak affecting your R4HA sound familiar? I expect so, since it happens all the time in pretty much every mainframe shop.

The ship’s captain really has no recourse, but mainframe CIOs do have a trick or two up their sleeves to handle unexpected events. I’m talking about automated cost optimization and workload handling – solutions that optimize performance while controlling monthly WLM charges. Soft capping without the capping.

The idea is that while workloads are increasing, and costs are rising, there are ways to control that – lower priority LPARs can donate unused capacity to higher priority LPARs running critical workloads. For example, when unexpected events threaten to drive increased costs, or even cap system performance on the Production LPAR, unused capacity from the Development and Test LPARs can be transferred to the Production LPAR to prevent cost overruns AND prevent performance capping.

Just what the captain needed…

Originally published on Planet Mainframe.