Shifting COBOL compute to less expensive platforms may be the best first step on the modernization journey. Identifying and moving the execution of your most expensive COBOL batch jobs provides an opportunity to reduce cost or free up funds in an existing IT budget. This modernization technique offers a low-risk, straightforward, and cost-effective approach that could lead to a reduction in your MSU usage spikes and MLC fees. If you move your COBOL compute to
As mainframe costs continue to rise, alternate compute and execution environments such as the zIIP, Linux, and the cloud are gaining more attention and credibility. Using cross-compile techniques to transform COBOL systems to Java creates opportunities for application owners and IT management to explore and prove the economics of hybrid environments that leverage less expensive execution. While IT organizations are getting comfortable with hybrid environments for enterprise applications, most still need to pull their mainframe
Mainframe costs continue to rise. Those increases have a tremendous impact on IT and business unit budgets. Not only are IT and business operations asked to do more with less, but adding insult to injury, the less actually may cost more. As organizations seek opportunities to reduce costs, one important area of potential savings should not be overlooked: COBOL execution on mainframe GPP. If organizations could shift COBOL compute or execution off of the mainframe
Developing a sound business case for your modernization projects is critical to success. The business case helps you communicate your modernization project’s impact, scope, cost, and lasting benefits. It lets you plan and rationalize the modernization choices you’ll make in the project. Without a strong business case, your project is less likely to succeed. Attend this webinar and learn about CloudFrame tools and processes to help you construct a financial business case for shifting COBOL
You’ve heard that COBOL cross-compile delivers Java byte code that allows you to move COBOL execution or compute to less expensive platforms. That includes the zIIP, cloud, Linux, or anywhere else a JVM is running. But, you’ve got questions. So many questions. You’re in good company because we get questions all the time! In this session, CloudFrame leaders reveal and answer the top questions. The webinar includes • The basics of COBOL cross-compile • The
When you hear “COBOL transformation to maintainable Java in 60 minutes” the reaction is predictable; eye rolls, thinking – “yeah right,” and suspicion. It’s understandable that you have a healthy skepticism when it comes to COBOL transformation pronouncements. After all, COBOL has been on the “replace” list for decades, and stories of failed projects are numerous and easy to find. CloudFrame wants to chip away at the skepticism and suspicion. Demonstrating and displaying our approach
The zIIP, an IBM specialty processor, allows organizations to reduce the workload of their general processors (GPs). This reduction can lower the MSU metrics used to calculate MLC software charges. Lower MSU usage can lead to lower MLC charges. Knowing that zIIPs may reduce your cost and achieve the benefit isn’t as complicated as you might think. Understanding how to leverage the zIIP for cost reduction is a CloudFrame Modernization Best Practice and can be
The drive to get COBOL applications into the cloud, and specifically Java, created a monster: JOBOL. It is the evil offspring of COBOL and Java when no planning, optimization, and design is applied to transformation. JOBOL is the byproduct of speed at all cost, check-the-cloud-box initiatives. But when modernization efforts deliver JOBOL to application teams, with its inheritance of complicated mainframe COBOL structure and bloated code base, problems arise. Development teams are reluctant to own
Organizations invest time and effort into new software products based on business plans and goals. They want to solve a problem, gain an advantage, or reduce risk and cost. One of the first steps on the new software journey is to establish that the product can do what the vendor says the software will do. Organizations want proof. That’s the purpose of the Proof of Concept (POC) engagement. An example solution scenario is tested in
COBOL modernization projects can be high-risk and costly. Especially if applications are modernized using a green-field rewrite approach. These projects can involve small armies of developers deployed for the heavy lifting of code production as they attempt to reduce the risk of extended project duration. Some of these projects are “successful” – often by tweaking the definition of success. The reasons for redefining success are varied. The code produced by the deployed army might be
Regular readers of my posts here know that zIIPs are a type of mainframe specialty processor that augments the general-purpose CPUs. Instead of running all workloads on the general-purpose CPUs, specific workloads are shuttled to the specialty processors for execution. The zIIP, or Integrated Information Processor, was initially created to process certain types of Db2 […]
Units of work that run on the mainframe, at least those running on z/OS, are dispatched using two different types of control blocks: TCBs (Task Control Blocks) and SRBs (Service Request Blocks). It can be beneficial to understand these two types of control blocks, including how they are used, the differences between the two, and […]
Cost is the primary driver for shifting COBOL compute to less expensive platforms. But once organizations decide that they are going to use shifting COBOL compute they discover there are other benefits to this modernization method. These benefits are realized in three areas: impact, risk, and momentum. Financial Impact The immediate benefit of shifting COBOL […]