Re: Productivity

Pete Dashwood<dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> 12/28/06 2:42 PM >>>

"Howard Brazee" <howard@xxxxxxxxxx> wrote in message
news:dnn7p2lh7524u11iuvt77dcchh76c53cfk@xxxxxxxxxx
On Thu, 28 Dec 2006 14:34:05 +1300, "Pete Dashwood"
<dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

Yes, COBOL is excellent for sequential batch processing and will fill
that
requirement for some time to come. Eventually, transactions will be
processed so fast that Batch will not be necessary, even reports will be
spooled online as transactions occur, and so there will be less
dependence
on Batch. Only historical reporting would need a batch approach. But
that
time is still a few years off yet.

I see lots of shops going with data warehouses on one side, and
on-line transactions on the other side - with interfaces between the
web servers accessing both. Where is batch CoBOL needed in that?

A good question. I hadn't considered that scenario. Thanks, Howard.

What about the manager who wants to know the total amount of transactions
processed today? I guess there would be something that uses SQL to do this,
selecting only transactions with a particular date. Not a bad idea.

I am very curious to know if there are any banks out there that work like
this. Additional things that a bank would have to worry about is when to
accumulate and/or pay interest, and when to cutoff transactions for an
account whose statement is cycling today. Seems to be that "batch
processes" would be required for both of those cases. Especially the
interest thing, because you essentially have to go through every single
account, even those that did not have any transactions today, and accrue
their interest (oh, and charge their fees! <G>).

It's not that I think such things are "impossible". More that they are out
of the realm of my experience, and thus fraught with many unknowns.

fRANK


---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
.

Relevant Pages