Re: COBOL Compiler for Windows

<docdwarf@[EMAIL PROTECTED]
> wrote in message
news:fvcpf4$ge8$1@[EMAIL PROTECTED]
> In article <6cnj14db0cpscakdtdacpotptrgtjnkf75@[EMAIL PROTECTED]
>,
> Howard Brazee  <howard@[EMAIL PROTECTED]
> wrote:
>
> [snip]
>
>>So which of these are going to soon be obsolete?
>
> Mr Dashwood's assertion did not address obsolescence.
>
> DD
>
Fair comment, Doc.

Before this spins out of control I better be clear about what particular 
flavour of "batch processing" I WAS addressing.

It was the "traditional" processing of "batches" of transactions. The
stuff 
that is currently done in overnight windows to update back end databases. 
However, I will extend it to include manually written DB scans that build 
reports. (as opposed to single queries or Lambdas where the RDBMS software

decides what will be scanned and by which processor and when...)

I said it would be redundant.

My reasons for that are as follows:

1. Before we had online processing, batch processing was the only 
processing. COBOL was ideally suited to it and this led to the development

of a culture that "took it as read".

2. When the first 3270 style displays appeared (running in 32K in
Foreground 
1) the processor power available was such that the entire updates required

by the online transactions could not be accomplished (and there were other

security considerations and backup implications) so transaction files were

written for processing in batch against the back end DB, and the online 
processing confined itself mainly to data retrieval.
As more sophisticated DB software arrived and processors became more 
powerful, online transactions were able to accomplish more and the need to

"complete" transaction processing in batch diminished. Batch processing
then 
became the domain of reporting which involved DB scans, and the deferred 
processing of batched transactions collected during the day.

3. My argument is that with modern networked processors parallel
processing 
and multitasking can simply do what once required a batch process to 
achieve. There will still be reports that are based around a time series, 
for example, and the data for each line of the report needs to be
collected 
from somewhere. However, if the problem is viewed differently from the 
traditional approach, different ways of achieving it become apparent.

For example, suppose a certain "monthly report" was viewed as a report 
"object" with a "collection" of report lines. The problem is now one of 
ensuring the collection covers what happened during the month. Using the 
traditional approach we might scan all the transactions between the 
requisite dates, do some figuring on each transaction, and place report 
lines into the collection from our batch scan.The collection would be
built 
by a single processor running a dedicated (batch) process.

But it quickly becomes apparent that that is not the ONLY way to build the

collection. Suppose, as each transaction occurred in real time it kicked
of 
a sub task (maybe running on a different procesor) that added the
necessary 
report 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 report 
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...)

The gist of my argument is that distributed parallel processing power
(such 
as will emerge in the next decade or so) will render traditional batch 
processing redundant. This also has implications for the "death of the 
mainframe" as discussed elsewhere...

As noted at the start, scans carried out by RDB software to resolve a
single 
query, and data warehousing/BI processes were also not included in my 
scope...

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