Re: Productivity


"Robert Jones" <rjones0@xxxxxxxxxxx> wrote in message
news:1167574958.426550.272040@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

message snipped

Pete Dashwood wrote

This, admittedly contrived, example demonstrates quite clearly the
fundamental difference between event driven (read, "on-line") and
non-event-driven (read, "batch") processing. OO lends itself to event
driven
processing; procedural programming doesn't. That is why OO is taking over
the world... (whether the people using it understand this or not... all
they
know is that Objects are flexible and responsive and designed to handle
events; procedural code simply isn't...)


While I can believe that COBOl will eventually be retired, I don't
believe batch processing will ever completely go away. Events such as
are invoked by as tax authorities wanting yearly company accounts and
tax computations are probably too much to suddenly throw at an on-line
system, there would probably be severe degradation of service, even if
many of the underlying figures had already been calculated. Events
such as monthly/weekly payrolls, cheque printing, etc also are probably
best done in a batch process.

I would also add that while the "we have always done it that way"
factor can be an obstacle, one also has to consider whether it is worth
the effort in making the change unless there is a perceived benefit in
changing something that already works, and who is going to provide the
budget and manpower to implement a new system.

Robert

You may be right. I concede that it is arguable.

All of the examples cited above could be produced as by-products of
transactional processing. Payrolls, certainly are good examples of a batch
process, but the same effect can be obtained by time-triggered processes
against a database.

(Imagine a payroll system where a stored procedure is triggered
automatically to calculate the base pay for an individual, and the tax to
be paid, and transactions that make adjustments to this have been enqueued
against the individual account. The whole process will run automatically and
all the paymaster has to do is provide the adjustment transactions in real
time. It doesn't HAVE to be batch, although, in essence, it is a
"batch-like" process, inasmuch as many people will have their pay
calculations trggered at the same time...)

Stored procedures and Data Warehousing, together, can obviate all the batch
processes I can think of. (I may have missed some... :-)) Printing cheques
will soon be a thing of the past; direct transfers and smart cards are more
secure and more convenient for the drawer and the payee.

Pete.


.

Relevant Pages