Archive for the ‘Mainframe’ Category

“You manage a mainframe environment that runs one or more of your business` mission critical applications. Things are good: security, performance and reliability are just where they should be. But when you think about your long term staffing strategy, you cringe, because most of the people on your mainframe staff have long term plans that include travelling, fishing and gardening … in other words, retirement.”

What starts like a mainframe’s farewell, turns out to be a mainframe’s hymn – in the Acxiom whitepaper about The Reality Facing the Mainframe World. The truth behind is that the predictions about the death of the mainframe, we have been listening to for 20 years (and the beginnings of networking), are not taken seriously anymore; even if mainframe staffing is supposed to be a tricky task nowadays.

Especially against the background of re-centralization it’s more than obvious that the mainframe is not only confronted with a reality. It is a reality – with “200 billion lines of COBOL code in existence and 5 billion lines of COBOL code added yearly” (according to eWeek).

Mainframe is here to stay. “It is alive and processing” – as the whitepaper points out. And it’s even more alive, if the processing of the mainframe AND the client-server world is done under a unifying roof of one comprehensive scheduler, I would like to add. Because it will not survive as an island. That’s for sure. The future is in the “cloud”. Maybe. And that would not be a good deal worse.

The necessary integration homework is described by this UC4 Whitepaper.


Read Full Post »

Talking about the benefits of automation often leads to certain degrees of abstraction with highly sophisticated arguments. Of course, thoughts about boosting availability and performance, about minimizing failure, risks and process costs are not abstract in themselves, but sometimes I am searching for a language even a bean counter could understand.

It’s for once not about how CIOs could argue for automation when meeting the board of directors. It’s more about searching for a fleshy argument which really convinces them first, keeping in mind that most of the time change is a bottom-up process which doesn’t start at CEOs desks. But what if they are so focused on keeping equipment running that they forget to keep score, or perhaps they see the benefits as so obvious that it’s not necessary to calculate them.

Maybe you could just take a moment and read this story. It’s about a CIO from a big UC4 customers I spoke with a couple of years ago. He was a mainframe guy originally, and remembered a time where any dysfunction in the data center was announced company-wide over a Brazil-like loudspeaker system. No wonder, that he start feeling awkward whenever he left his office for inspection walkways or team meetings. This was before the automation project. “Now, it’s different and enjoyable to make my round, because there are no such announcements anymore” he attested when we get on to the benefits of automation.

I will always remember him grinning from ear to ear.

Read Full Post »

In today’s IT environment, it is still common for enterprises to use two or more job schedulers – one for the mainframe and another for the remainder of the enterprise. This practice stems from the belief that mainframe-specific schedulers are superior to those that offer centralized control and automation for both the mainframe and the entire enterprise.

The following are some key misconceptions regarding legacy mainframe schedulers that often lead IT managers to believe they need to maintain two schedulers at once.

  • Myth 1: A mainframe-specific scheduler is the most reliable solution for managing mainframe jobs. But actually a mainframe scheduler is limited, whereas an enterprise scheduler can be relied on to process any job throughout the entire enterprise. And: It can be implemented for non-stop operations while improving scalability across any number of CPUs and physical servers.
  • Myth 2: A mainframe-specific scheduler is the most stable solution for managing mainframe jobs. In fact, an enterprise job scheduler allows the most stable scheduling by providing visibility and control – for the entire enterprise – in one location. Processes can constantly be monitored and the manager can be assured that everything is running properly through a centralized GUI.
  • Myth 3: Using a mainframe-specific scheduler keeps business-critical jobs under control. But what about the business-critical jobs which are not kept on the mainframe? There is no assurance that the mainframe scheduler can see the job through to its end if the job is integrated across the entire enterprise. An enterprise-wide scheduler can monitor all business-critical jobs across an enterprise, ensuring completion.

What about you? Wanna add some more?

Read Full Post »

Just think for a second about travelling to work. Why do many people still prefering to travel by car? Not because cars are faster, but because they hate changing vehicles – getting out and waiting and getting in again and never really feeling seated. The connection is the bane of public transport, for sure, and it seems that it’s also the bane of process automation. Because what people hate is disruption.
Look at the picture below and think about your IT environment as a city. You will never reach this point, where all the houses and the streets look the same. And you hopefully never want to reach this pointwhere everyhting is uniform.
Becasue IT (like a city) is changing all the time you have to embrace change. That’s your only chance. Because you never draw IT landscapes from scratch, your main concern should be the connection between the legacy districts. The interfaces. If this is solved, you can lean back and enjoy the pluralism of your town. This UC4 whitepaper shows how to make your existing scheduling tools shape up to deal with variety.
UC4 landscape

IT landscape: to enlarge click the picture!

Read Full Post »