FICO® Blaze Advisor® Discussion

[kelvinks]

We need a new quotation engine and two key non functional requirement (a) Optimize MIPS consumption and (b) Minimum impact to mainframe application developed in Cobol

At the moment we are thinking to go for  Blaze Advisor  (COBOL code generation) under zOS”.

We wants to understand if the combination running Blaze Advisor under WebSphere zOS + local adapter can yield (1) “Better/Optimize MIPS consumption” and at the same time achieve (2) “Minimum impact to existing Cobol Application” and (3) We also need to consider the solution from the cost effectives point of view.

1. Any people have similar experience ?

2. What are consideration points ?

3. Any chance Blaze under WebSphere zOS will consume less MIPS compare the native Cobol version ?

Any input is welcome :-)

Cheers

[Tas · Accepted solution]

Hi,

The trade-off here is going to be whether or not RETE would significantly optimize the decision processing.  Blaze COBOL does not implement the RETE network.  However; the generated COBOL routine is directly called by the main application and is directly compiled into machine code.  So, there is no transition to the WAS region and no JVM involved.  

So what this means is that large rulesets that can be optimized by the RETE engine will perform better under the WAS region because RETE will optimize rule execution.  All other decision processes will execute better under a compiled COBOL subroutine. 

Tom Sheckells

Business Rules Consulting, Inc.

[kelvinks · Accepted solution]

Hi Tom:

Many thx for the reply.

If my understanding is correct, you mean  compiled COBOL subroutine will be faster unless there is RETE involved.

In short COBOL version is faster on zOS.

On the other hand, we are wondering whether it is "cheaper" to run the java version in terms of MIPS (CPU) usage undert zOS as Rule engine is typically CPU bound.

The reason behind is that zOS get this special  Application Assist Processors (zAAPs) hardware as IBM put

"When configured with general purpose processors within logical partitions running z/OS, zAAPs may help increase general purpose processor productivity and may contribute to lowering the overall cost of computing for z/OS Java technology-based applications. zAAPs are designed to operate asynchronously with the general processors to execute Java programming under control of the IBM Java Virtual Machine (JVM). This can help reduce the demands and capacity requirements on general purpose processors which may then be available for reallocation to other mainframe workloads.

The IBM JVM processing cycles can be executed on the configured zAAPs with no anticipated modifications to the Java application(s)"

Any help is appreciated.

Cheers

[atdemmin · Accepted solution]

Kevlinks, I believe I can provide some assistance as well.  I have implemented Blaze projects both as COBOL deployments running in batch and under CICS, and also as Java EJB's running on WebSphere for z/OS, communicating with COBOL modules through WebSphere MQ (message passing).  I have not implemented CORBA communication (probably not worth it anymore), but I have toyed around with COBOL through C through Java/JNI to a Blaze Java application deployment.  The MQ solution was easier and fast enough for my needs at the time.

First off, there is no RETE with a COBOL deployment.  A COBOL deployment generates a COBOL program, which is just a sequential execution of your rulebase.  Most likely, it will not be faster than the same service written in native COBOL.  This is simply because the translation from Blaze SRL to Blaze COBOL will generate code that won't be as efficient as if it was written in COBOL from scratch.  However, with some care taken with your SRL coding, you can still generate acceptable runtime behavior.

As far as Blaze running on WebSphere for z/OS, I have not yet implemented on a zAAP processor, I would really like to see if this can improve the runtime.  When I compared my EJB on WebSphere for z/OS against WebSphere for AIX, I was able to achieve a similar throughput.  However, my experience is that Java on a mainframe is still very expensive.  You may be able to achieve acceptable performance, but the MIPS cost will probably be significantly larger than you expect.  Of course, this is a problem if your are charged by the instruction!  Will you still have to pay per instruction on the zAAP processor?  If not, this could make it much more appealing.

Bottom line, you can create Java services that execute on both Unix-based distributed servers and will also deploy to WebSphere for z/OS (you just have to handle ASCII/EBCDIC conversions), but expect the MIPs cost to be high.  It may be high enough that you have to consider a dedicated Unix-based (AIX) box to run your Java Blaze service and communicate using MQ (message passing).

From a MIPS perspective, a Blaze COBOL deployment will be much faster and much cheaper than a Blaze Java for z/OS deployment, even with a zAAP processor.  The drawback is accepting the Blaze coding limitations with a COBOL deployment, which may be ok if you are dealing with legacy systems in the first place.

Hope all this helps,

Alan

[kelvinks · Accepted solution]

Many thx Alan. Your answer is very helpful.

Will  try to talk to IBM directly and keep you guys posted if I got anything specially on whether Java on a mainframe is still very expensive.

By the way if I want to learn more RETE any idea where I should start ?

One again many thx for all of you spend your time in answering my questions

Cheers

Kelvin

[Tas · Accepted solution]

Hi Kelvin,

Here are two places to start: http://en.wikipedia.org/wiki/Rete_algorithm.  Some background on the whole topic.  And: http://techondec.wordpress.com/2011/03/14/rete-algorithm-demystified-part-2/.  These two will get you started.  Finally, for more, Google is your friend.

Tom Sheckells

Business Rules Consulting, Inc. 

[atdemmin]

kelvinks, that sounds good.  IBM developed zAAP specifically to address offloading Java workload to a special optimized processor and the cost should be lower since it shouldn't be included in the MIPS rating like a general processor.  However, I don't know if data centers have flexibility on the way they charge for these processors either, so it may come down to that.  Have you heard of IFL (Integrated Facility for Linux)?  This is another IBM offering that was on the horizon at the time, but I have yet to implement.  It is basically like having a separate Linux partition on your mainframe.

When I was pursuing this back in the early 2000's I was at an IBM conference and was strongly encouraged to "take Java off the big iron", but soon after things really changed and I saw a committment from IBM to make Java on the mainframe a viable solution.  Good luck and let me know what you find out, I am itching to get back and try out a zAAP engine.