Re: IBM file status 97 (was: Prodcuing an output file onlyonFriday?

"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:4bf88oF1199dvU1@individual.net...
> Pete Dashwood<dashwood@enternet.co.nz> 04/28/06 8:06 AM >>> 
> 
> 
> knows...
>
> But would these other languages and environments perform as well, or near
> enough, as COBOL on a mainframe?

That would be irrelevant if COBOL was no longer an option.


> Let's say we take our 30000+ line demand
> (checking) account posting program that runs once a day to post the day's
> transactions, accrue interest, assess fees, creates statement records for
> those accounts cycling today, etc.  Let's say there are 400,000 accounts
> and
> 1,000,000 transactions.  We can process that right now in about 20
> minutes.
> Let's say we want to "convert" that process to Java.  We have the
> overheard
> of the JVM and the fact that Java does not have a native decimal type (you
> either use floating-point, which I believe is a no-no in financial
> calculations, or you use BigDecimal which is a class, not a native type.)

(There is no divantage to using a class...)

Sure, I think you're right. But you are thinking within the framework of
what you do now.

"Convert"ing to Java is only one option.

Suppose all the accounts were posted online as transactions occur. Suppose
all the other activites like accruing interest, assessing fees, etc were
carried out by other asynchronous objects that were triggered by the
transaction. (Possibly even as backend stored procedures, kicked off when
the posting is made.All you need to do then is optimise your DBMS. Even if
you didn't go for stored procedures, the parallel processing available on a
network is not to be sniffed at...) Statement lines could be posted to a
Store and Forward repository and pulled off for printing in any format you
like, or presented on screen.

For the same price as a mainframe you could have a number of servers with
your 400,000 accounts optimised across the server configuration. Load
levelling could be used as well. Such a configuration could easily attain
50,000 transactions a second (it is multiprocessing in parallell) so even if
your 1,000,000 transactions occurred simultaneously, it would take the
cluster 20 seconds to clear the backlog. But you wouldn't need to scale to
that level on day one. You would analyse the current transaction levels and
implement accordingly. The configuration is then scaled up as the need
arises or service levels fail to be met.

And all of the above is just ONE possible approach. There are many.

"Converting", while it is the most obvious strtategy, may not be the best.
It might be possible to allow some of the functionality currently carried
out by the batch process to be moved to transaction processing, (with the
batch processing still being run but having to do less) and progressively
scale this so that eventually everything is processed online.

Specific functions you mentioned above might be refactored, wrapped, and
presented as SOAs.

There are many possible solutions.

> Just based on those two factors, what type of performance might we expect
> compared to COBOL?  Of course neither of us knows, but I imagine it might
> be
> several orders of magnitude more for Java.  Maybe I'm wrong.  That's just
> my
> impression from things I've read and from using Java here and there.

I think you're right, but you would not run a Java shop in the same
environment you are currently running.

>
> Not to defend COBOL in and of itself.  It's just I simply don't know of
> any
> other language that is better suited for financial applications.  I would
> love to have a language that has all of the strengths of COBOL but also
> all
> of the strengths of other more modern languages.

Or, better still, why have a "language" at all? Why not combine encapsulated
objects into system solutions without caring what they are written in or who
wrote them or having to maintain them? :-)

Pete.