GT Software BLOG

I have been working with mainframe computers since 1982.     With the Ivory Service Architect Studio, I have done hundreds of demos and POCs where I have imported BMS maps, viewed the BMS source, etc.  But one thing I have never done is either hand code or maintain a BMS map. I guess, looking at the complexity of the BMS macro source, one thing I can say it that the Macro code is not something I would want to code by hand.  The good news for you and me is that with BMS/TS and Ivory BMS from GT Software, you never need to write another line of BMS Macro code.   More importantly, you also don’t need any training. 

With BMS/TS, you simply open up a WYSIWYG screen painter on the mainframe, design your map by laying out the screen right in front of you, and submit the map to the LOADLIB.  Customers have experienced up to an 80% productivity gain over hand coding maps.  And if you prefer using a Windows development tool, Ivory BMS allows you to create and maintain maps right on your desktop.  You don’t even need to be attached to the mainframe.  So why would you ever want to hand code a map again?

http://www.gtsoftware.com/content/ivory-service-architect

dspoerke Random

One of the biggest challenges we face in life is not wanting to pay for the whole bowl just to get a taste.   If software companies were like ice cream shops, they would have a little bowl of spoons that would allow you to try web services before you bought a whole bowl, or whatever the mainframe equivalent of a bowl is.    GT Software announced this week that if you want to start slow, or just dip your toe into the water of web services, that you can pay as you go.  More specifically, you only pay for the web services you put into production and actually use.   

By taking “financial risk” off the table, an organization can truly focus on the business value of mainframe integration.   To further mitigate risk, the Ivory product line offers deployment of web services to a range of platforms off the mainframe so additional mainframe workload can also be taken off the table.   If you want to stay on the mainframe, we will leverage MIPS reducing hardware such as zIIP, zAAP and the IFL processors with zLinux.

This is a radical departure from what you get from the traditional software licensing model, but we are so confident that once you try Ivory, you will be successful.   “GT Software deserves praise for taking some of the user’s risk onto its own shoulders by only charging for customer success,” said Steve Craggs, Principal Analyst at Lustratus Research. “Too many vendors throw fee-based or even free software at projects and then walk away, leaving users to struggle to achieve value and carry all the risk. By linking its own reward to user success, GT Software creates the best possible win/win incentive.”

dspoerke Random

I took the Ivory Service Architect and created a very nice service based on IMS transactions. I then went into the Oracle BPEL process manager and created a BPEL process that included the aforementioned service.

So in a matter of ten minutes I had a BPEL business flow that call the IMS service as a partner-link(BPEL – Speak). I also created a composite service in Ivory that actually orchestrated multiple IMS transactions , then included that into a BPEL flow, which means the orchestration takes place on the mainframe where it belongs and does not require the BPEL tool to have to deal with multiple mainframe transactions. So yes you can easily include “ANY” mainframe artifact in a service that can be included into a BPEL flow…in minutes, not days or weeks.

Dusty Rivers Mainframe, Mainframe SOA BPEL, IMS, Oracle

In meeting with most IMS customers, most of the old IMS systems staff have for years been writing their own solutions. In most cases the product did not have a tools following so many customers just gave the IMS System group the guidelines and they wrote tools and utilities. The only problem is that the solution then took on a life of its own and consumed resources and staff just to keep the homegrown tools viable. As I go and talk to IMS customers about Ivory and SOA and how easy and straightforward the solution has become, I often hear…

1) have written some of their own  or

2) they have taken a few of the “free” IMS tools and force fit them together for a patchwork solution.

The issues that come up are extensibility, scalability and performance. To add a new function to a home grown solution in reacting to a new feature in IMS or try to get an old tool to work with new applications often causes more work than the worth of the actual solution. So it’s time to resist the urge to write your own DIY solution and let the vendors worry about all those details, versions of IMS, features of releases and other issues. Because at the end of the day the IMS systems will be around for decades, but the homegrown solutions will not react in kind. Resist the urge, don’t do it yourself.

Dusty Rivers Mainframe IMS

One of the biggest  integration challenges  many developers have faced over the years is what to do about the data.   Especially when that data resides on the mainframe.   Over the years, programs have been written, FTP processes executed, ODBC/JDBC based applications created, none really providing a seamless and straight forward way of integrating data.

With the increased popularity and acceptance of web services, one must not forget about the data.  Having a strategy for providing data access from within a coarse grained service, or as part of a fine grained or business service, is crucial to the success of an SOA strategy.   By using a standard web services interface to the data, no programs need to be written, no FTP processes created, and there is absolutely no need for ODBC or JDBC.    This capability adds a dimension to composite services that lends a great deal of flexibility.   Imagine doing a database lookup and passing that data into another application without writing an application to get that data.   This is the nirvana of data integration.

dspoerke Mainframe SOA, Random data services, SOA

I have had many discussions lately with IMS companies that end with that statement. In fact, you can substitute “IMS” with “mainframe” in that sentence too.  Too often companies think that to modernize means they need to scrap what they have and move to a new platform. No new functions, no new business value; just move to a different platform and all your issues will go away. Most of these IMS systems have been running fault free, day in day out for decades, and will continue to do so. Companies forget that to actually move off of IMS there would be huge costs (programming, analysis, testing, and acceptance from users) and the effort would take years, to only give the company a new platform and no added value to the bottom line.  Several questions should be asked the next time they say — “we are moving off IMS”; Why?  What new functions are we implementing that address the user’s or business’s needs? How will the new system add to the bottom line?  Maybe the consultants that suggested it are looking at a multi-year billable deal and not looking at functionality. IMS has been around for 40+ years and will continue to function. Maybe the real question should be to ask the users; what other information, what other processes and data do you need to provide? Then look at ways to provide those needed assets and functions by reusing what is already in place with state of the art integration technologies such as web services.

Dusty Rivers Mainframe IMS, mainframe migration

So many times we hear that bigger is better. I would argue that when it comes to web services, smaller is better. It is very easy to be drawn in by the idea of taking a copybook, creating a service, without any regard for what is in the copybook. When we need a gallon of milk, we don’t go and buy the entire store! We get only what we need. The same should hold true for web services. Too many times we try to create services that cover all the possibilities anticipated. I would argue this type of approach is too broad and would incur a significant amount of unnecessary overhead. That is not to say that every service needs to be absolute either. Tacking on an extra field or two for the sake of reusability would not be a bad idea. When thinking about the size of the service, remember size does matter, and that is the right size.

dspoerke Mainframe SOA service granularity, Web services

• Creating dynamic new content for our customers showcasing Ivory in multimedia snippets. #

Rob Morris Random GT Software, Mainframe Integration, Mainframe SOA

Let’s face it — shifting workload from the general purpose processor (GPP) to the zIIP, zAAP or IFL mainframe specialty engine is smart.  Really smart.  IBM’s desire to make the mainframe a more attractive platform for new workload may dramatically slash the cost of mainframe integration and SOA projects.

The reduction in CPU consumption offered by properly leveraging specialty engines tells a compelling story.  Run your workload on a specialty engine and not only save money, but achieve higher performance.  A no brainer, right?  Well….not exactly!  As you would imagine, all workloads are not created equal.  A major issue is the ability to selectively choose which workload remains on the general processor, and which is sent to the specialty engine.

Just because you can send mainframe SOA or integration workload to a specialty engine does not mean you should. There are many use cases where it is much more efficient to NOT shift workload to a specialty engine.  Why — because, there is overhead associated with moving workload from the GPP to the zIIP or zAAP engine.  The cost will vary by situation, but a good rule of thumb is that if you shift “small” workloads from the GPP to a specialty engine the savings will not cover the CPU overhead of moving the workload.

Therefore, the “smart” approach to maximize savings and performance is to be able to discretely manage the workload that is sent to the specialty engine vs. what remains on the GPP.

Another degree of required flexibility is the ability for you to choose which specialty engine to utilize. Some enterprises will have a zIIP, others a zAAP, while others may have the zIIP, zAAP and IFL engines.  Organizations simply have not made a strategic commitment to one engine vs. another.   We often see companies starting with say a zAAP engine, and then change their mind and switch to a zIIP or IFL.

Therefore, the “smart” approach to de-risking your specialty engine commitment is to ensure the products you utilize for mainframe SOA and integration can leverage all three specialty engines, as well as not standing in the way of changing to a different specialty engine tomorrow.

Let me be clear — vendor solutions that mandate an “all or nothing approach” do so because of shortcomings in their vision and technology.

Using specialty engines is definitely smart, managing workload on a service by service basis to maximize MIPS savings without sacrificing one bit of performance is what we call “being smart about leveraging specialty engines.”

Rob Morris Mainframe cpu consumption, cpu workload shift, IFL, integration workload, Mainframe Integration, Mainframe SOA, purpose processor, zAAP, zIIP