Re: Recommendations for a newcomer?

yes, however,
in your example of P&G...
yes, individual transactions roll up into centralized databases...
but when it comes time for P&G to order more coffee, there is not
some SQL/PHP/Java code attached to the scan transaction...
there are HUGE BATCH PROCESSES that trigger the ordering..



On 5/14/2013 3:31 PM, Dan Kimmel wrote:

With few exceptions, "batch processing" is a dead horse. Today's systems process transaction at a time directly from whatever capture mechanism is used. Data entry on a keyboard is fast becoming extinct. We grab information in barcodes at a retail checkout or IFR tags in a warehouse. Even those transactions are processed transaction-at-a-time. Proctor and Gamble knows my wife has purchased a can of Folgers before she swipes her credit card at the local Walmart.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Gqcy
Sent: Tuesday, May 14, 2013 3:21 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Recommendations for a newcomer?

Dan,
are you saying that "batch processing" is to be replaced?

or can you provide some examples of where SQL would "be a better batch transaction processor"?




Paul Nelson wrote:
> Name a better batch transaction processor than RPG or COBOL, please Dan Kimmel wrote:
>SQL
Paul Nelson wrote:
> Now go write me a payroll timecard processing program in SQL.

On 5/14/2013 3:08 PM, Dan Kimmel wrote:

Payroll time card processing is not a batch application. It's a user interface transaction...

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.