Re: COBOL and DB2 vs. Java and DB2

On Sun, 16 Sep 2007 08:59:05 -0500, "Judson McClendon" <judmc@xxxxxxxxxxxxx> wrote:

"Charles Hottel" <chottel@xxxxxxxxxxxxx> wrote:

What I find particularly interesting in this regard is that the specifications for the new system say 95% of the transactions must
be processed in 30 seconds, and 99% of the transactions must be processed in 60 seconds. Wow! To say I am underwhelmed is a gross
understatement! Currently using COBOL and Datacomm/DB we process transactions in less than one second. This is from the time the
transaction (a message) is removed from the queue (MQSeries is used) until the time when the reply is placed onto the outbound
queue. If this is modernization then I just don't see the point especially when it is costing 300+ million a year. Or many
making money is the point!

In the situations I am familiar with, traditional mainframe databases blow
the doors off SQL type approaches. Whoever designed SQL must have
been entirely clueless, or indifferent, to machine efficiency.

Everyone who's run a Google search knows that to be untrue. It displays the time it spent
searching three billion Web pages. I just did it with four wildcard words -- "for * * nail
the * was lost". It found 27,000 in .08 seconds. That's fast!

Interesting trivia: the Oracle FAQ at http://www.orafaq.com/ runs on MySQL, not Oracle.


Last year the State of Alabama went from a mainframe based driver's
license system to a client server based SQL system. Processing times went
from about a second to several *minutes*.

Slow performance was caused by a Federal requirement (Real ID) to verify the driver's
Social Security Number with a Federal computer. Alabama was the first state to use that
network, which was not ready at the time. It has since been speeded up. All must use it by
the end of 2008.


.

Relevant Pages

  • Re: NexusDb
    ... > At no time did I query your evaluation of the SQL statements. ... > That really only leaves the question of Transactions IMO. ... specific SQL commands that support starting, ...
    (borland.public.delphi.thirdpartytools.general)
  • Re: NexusDb
    ... >> because we mostly use SQL queries in our projects, SQL support is ... As evidence review your ... Whether this means that the SQL transactions have to be ...
    (borland.public.delphi.thirdpartytools.general)
  • Re: What are some ADO & ASP.NET best practices
    ... Maybe it's a common query in your database not using ... dedicated to ADO.NET and SQL Server performance tips: ... Improving .NET Application Performance and Scalability ... >My next question is will transactions help to improve performance? ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: SqlTransaction.ZombieCheck error
    ... The reason is that Transaction ... SQL Server automatically rolls back the transaction for insert issues caused by Datetime conversion errors. ... Simply wrapping batches of inserts together in a transactions has shortened processing time of my app nearly in half. ... I'd still appreciate it if you relayed to the SQL Server Team my comments about the severity and the fact that Atomicity isn't the only reason to use transactions. ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: C# transactions v SQL transactions
    ... SQL 2005 has some improvements, but that's not here, and if you are ... >SQL Server stored procedures, but it seems to lack many of the benefits ... >of C# transactions - a lot of the errors don't seem to be trapped by the ... >in stored procedures rather than your .NET code, ...
    (microsoft.public.dotnet.languages.csharp)