Re: (not entirely...) OT: OPINION... chicken entrails, runic stones, and crystal balls... WAS CoBOL moved to OO
From: Pierra (pierra_at_sprynet.com)
Date: 01/03/04
- Next message: Habitant: "Re: No panic - but .. Y2K + 4"
- Previous message: Gunnar Opheim: "Re: COBOL Standards Issue"
- In reply to: Doug Scott: "Re: (not entirely...) OT: OPINION... chicken entrails, runic stones, and crystal balls... WAS CoBOL moved to OO"
- Next in thread: Doug Scott: "Re: (not entirely...) OT: OPINION... chicken entrails, runic stones, and crystal balls... WAS CoBOL moved to OO"
- Reply: Doug Scott: "Re: (not entirely...) OT: OPINION... chicken entrails, runic stones, and crystal balls... WAS CoBOL moved to OO"
- Reply: Richard: "Re: (not entirely...) OT: OPINION... chicken entrails, runic stones, and crystal balls... WAS CoBOL moved to OO"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 03 Jan 2004 19:44:15 GMT
Two things about the topic at hand.
1. If all the payroll processing is done dynamically/real time - how do
you balance it? When I was doing payroll processing (tax changes and
converting the print process from internal to external) balancing was
critical. It was part of the process of generating checks and posting
the fact that payments were made (as well as calculating and posting
benefit information.) Again, balancing was/is critical. Balancing is
kind of hard to do in an interactive environment.
2. I've had this argument in the past (not payroll initiated.) Batch
processing (single program/process or multi programs) can happen either
in a traditional batch environment (separate partition/region from the
online processing region(s)) or the online environment
(CICS/TSO/WINDOWS/etc.) My favorite term for the online batch approach
was OLB - On-Line-Batch! It's the same thing. The only difference is
how it's initiated.
Traditional batch is initiated by a job scheduler, operator submission,
or on-line user submission.
OLB is initiated by a trigger or on-line user submission.
During the last conversion project I worked on, the end users were
furious that they now would have to remember to initiate their periodic
processes because the traditional batch operator was gone.
Just because the tools change, does not mean the the functions go away.
***
Doug Scott wrote:
> Peter,
>
>
>>It just needs imagination.
>
>
> By its very nature, payroll is time-synchronised. Real time or
> interactive transactions are relevant where people work in different
> cost centres within a payroll period, so that part of it can be
> interactive. But the employee is paid weekly, or monthly or whatever.
> That then becomes a batch process, because no further human interaction
> is required to produce the results - just a tick of the clock.
>
> Similarly, share dividends are declared and paid annually, quarterly or
> whatever time period they decide. Once the dividend allocation is
> declared (a single transaction), millions of payments can be
> originated. Doing that via a real-time interactive system would
> probably dim the lights, but have no other effect on the result. Do it
> in batch background, and let the users get better response times.
>
> ---
>
> Doug
>
> dwscott@ieee.org
>
>
- Next message: Habitant: "Re: No panic - but .. Y2K + 4"
- Previous message: Gunnar Opheim: "Re: COBOL Standards Issue"
- In reply to: Doug Scott: "Re: (not entirely...) OT: OPINION... chicken entrails, runic stones, and crystal balls... WAS CoBOL moved to OO"
- Next in thread: Doug Scott: "Re: (not entirely...) OT: OPINION... chicken entrails, runic stones, and crystal balls... WAS CoBOL moved to OO"
- Reply: Doug Scott: "Re: (not entirely...) OT: OPINION... chicken entrails, runic stones, and crystal balls... WAS CoBOL moved to OO"
- Reply: Richard: "Re: (not entirely...) OT: OPINION... chicken entrails, runic stones, and crystal balls... WAS CoBOL moved to OO"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]