Re: Productivity


"P. Raulerson" <paul.rl@xxxxxxxxxxxxxx> wrote in message
news:pQDlh.78496$V34.25214@xxxxxxxxxxxxxxx
Just my two cents - Data Warehousing often requires a really staggering
amount of data manipulation and reduction before it is stored in the
warehouse. COBOL, in particular BATCH COBOL, is really good for this.

As experience is gained, Data Warehouses become better. Designs improve,
processing is faster, facilities are more diverse. I know one company where
NO COBOL has ever been used, and yet their Data Warehouse provides
incredible support to their business. In particular, cubes can be updated
from online transactions and automatically consolidated by the warehousing
software. No batch processing is involved, as far as I know.

Secondly, OLTP systems usually have a batch processing back end to them
somewhere or another.

Only because that is how it has "always been done"... :-) (See Michael's
comment elsewhere).

I addressed this in my response to Frank, in this thread, on 30th December.
Smarter transactions, running on more powerful processors can obviate batch
processing. DW software facilitates this.

A properly implemented DW (and I think this may have been Howard's point)
can obviate a good deal, if not all, of batch processing.


BATCH processing is just cheaper and faster, and as such will stick around
for a long time to come. ;)

I believe it will, but NOT for the reasons you state. It ISN'T cheaper
(compared to an on-line transaction that sets up accrual in real time) and
it certainly isn't faster. Adding online accrual to a transaction, for
example, means it only accesses "today's" data; a batch process would have
to look at EVERY day's data. You might thik that processing cycles consumed
should be the same, but it ain't necessarily so...

(Consider an online transaction that calculates interest on an account which
last had a balance change 3 weeks ago. The transaction can access a
collection of interest rates for the dates between then and today and
calculate the accrued interest; it only has to calculate for one period (the
time since the last balance chage). It "knows" the balance changed because
it is the transaction that changed it, and it wouldn't be running UNLESS the
balance changed...

A batch process doing the same job uses a "brute force" approach, looking at
every account every night, whether the balance changed or not, because it
can't know whether the balance changed until it looks at it... :-) Total
processing cycles consumed (especially EXCPs, if you work in an IBM
environment) will be (much) higher for the batch process.)

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...)

Talk to your Ops Manager about the effort required to get everything
processed through the overnight "Batch window"... You can see Ops people age
every time a new system with Batch processing is released...The usual
solution is to throw more hardware at it, but then there is all the
paperwork and hassle of getting approvals... Politically, it is much easier
to get approval when online transactions have slowed, because they are so
much more visible.

I think Batch will be with us for a few years yet, as I stated before, but
it won't be because it CAN'T be decommissioned; rather, it will be because
that is what is in place, and it will take a while for the DWs and networks
to achieve the power that can obviate it, and for managers to wake up to
that fact.

COBOL is again, good for that.

Yes, it is. Outstanding, in fact.

And canvas was superb for driving square-rigged sailing vessels.

But you won't find a lot of it on a container ship.

Pete.



.

Relevant Pages

  • Re: COBOL Compiler for Windows
    ... Before we had online processing, batch processing was the only ... to "complete" transaction processing in batch diminished. ... suppose a certain "monthly report" was viewed as a report ... however the cheques are encoded you are still left with a ...
    (comp.lang.cobol)
  • Re: COBOL Compiler for Windows
    ... flavour of "batch processing" I WAS addressing. ... to "complete" transaction processing in batch diminished. ... requisite dates, do some figuring on each transaction, and place report ... however the cheques are encoded you are still left with a ...
    (comp.lang.cobol)
  • Re: COBOL Compiler for Windows
    ... flavour of "batch processing" I WAS addressing. ... to "complete" transaction processing in batch diminished. ... time series, for example, and the data for each line of the report needs ... however the cheques are encoded you are still left with a ...
    (comp.lang.cobol)
  • Re: Transactions and Scope_Identity
    ... A batch is anything that ends in a GO. ... The transaction is probably shielding you here, so you are unlikely to have ... and return scope identity there. ... The insert command runs and then next command is SELECT ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Inserting Multiple Rows
    ... In addition to that [BCP, BULK INSERT, DTS], it might be worth mentioning below two things. ... Group several INSERT in the same transaction. ... Each batch requires a network roundtrip, ... mean what we see as "GO" in Query Analyzer and the method you use in ADO.NET to send the command to SQL Server ...
    (microsoft.public.sqlserver.programming)