| Clark Morris 2006-08-09, 6:55 pm |
| On Sun, 30 Apr 2006 13:25:41 +1200, "Pete Dashwood"
<dashwood@enternet.co.nz> wrote:
>
>"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
>news:4bf88oF1199dvU1@individual.net...
>
>That would be irrelevant if COBOL was no longer an option.
>
Performance is a matter of a given amount of throughput for a dollar
(yen, etc.) amount. It really doesn't matter if it takes 20 40 gig
servers as opposed to one mainframe if the 20 servers are cheaper.
COBOL can be an option. After all many of us learned most of the
languages we use by reading the manual and existing code. Business
programmers who were hired internally because of their business
knowledge have had to be trained on the tools. I think that the
emphasis on computer science for business data processing is misguided
and if anything has lead to more of a chasm between the people using
the tool (computer system) and the people creating and modifying the
tool.
>
>
>(There is no di vantage to using a class...)
>
>Sure, I think you're right. But you are thinking within the framework of
>what you do now.
Let me see the generated code before I agree with that one. Early
binding can give a lot of efficiency at the cost of rigidity.
>
>"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.
>
>
>I think you're right, but you would not run a Java shop in the same
>environment you are currently running.
>
>
>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? :-)
I agree that it is better to maintain a higher level. I really don't
want to program the actual reading of data. However, the script /
program / menu collection / etc. still has to be tested and
maintained. The tables provided to package of choice or affliction
such as SAP really should be thoroughly tested and records kept of the
settings and why. I would hope that we have advanced over the
packages and home grown systems that I have seen to the point where
all of these tables can be listed with explanations as to the effects
of the values. However I fear that in all too many organizations
these are either another black box no one understands or entities that
are changed without checking for side ramifications.
>
>Pete.
>
>
|