Re: COBOL Compiler for Windows

"tlmfru" <lacey@[EMAIL PROTECTED]
> wrote in message 
news:ajGSj.111848$Ft5.38403@[EMAIL PROTECTED]
>
> Robert <no@[EMAIL PROTECTED]
> wrote in message
> news:kdtk14pk2oococs6u2ruukcbhmtqmv9ck1@[EMAIL PROTECTED]
>> On Fri, 2 May 2008 11:55:22 +1200, "Pete Dashwood"
> <dashwood@[EMAIL PROTECTED]
>
>> wrote:
>> > Suppose, as each transaction occurred in real time it kicked of
>> >a sub task (maybe running on a different procesor) that added the
> necessary
>> >re****t line to the collection right then and there... No need to
filter
> by
>> >date or scan databases, just create the line in real time. (The re****t
>> >object could contain a method that filtered its own collection by date

>> >as
>> >the lines were sent to the print spool. You can argue that this is
also 
>> >a
>> >batch process, but it isn't within the scope I defined above...)
>>
>> It's called a Materialized View in Oracle. You don't have to write
> anything except
>>
>> create materialized view foo
>>   build immediate refresh on commit enable query rewrite
>>   as select customer, count(*) from customers group by customer;
>>
>
>
> I don't know if this process answers the obvious concern that PD's
> suggestion doesn't seem to address: that of the posted information 
> remaining
> correct until it's "printed" or otherwise disseminated.  Example: credit
> card monthly statements or any A/R listing: customers change their
address
> between the time the transaction is posted and the time the re****t is
> printed.   What's the phrase - you don't commit to a changeable piece of
> information or the results of a calculation until you actually have to.

Yes, that's a good point.
>
> Of course you could have a trigger associated with a customer address 
> change
> which would go in and change the information in the ac***ulating file
but
> that opens up a whole host of related issues (such as whether the
changed
> information adds a line or two to the address).  There is a level of
> complexity in the on-the-spot real-time approach which, if exceeded,
makes
> the old-fa****oned batch approach seem very sane and desirable.
>

Good points. I was more concerned with the concept than the details.

It may well be that batch processing will run on dedicated servers for
some 
time to come. My point was that it doesn't have to and it won't do so 
forever. The real point is that a lot of batch rocessing is done because 
that's how we've always done things.

I believe the advent of prolific and powerful parallel processing will 
change a lot of traditions...

Pete.
-- 
"I used to write COBOL...now I can do anything."