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: RH: "Re: Confessions of an "OO Foreigner"" 
    Date: Sat, 03 Jan 2004 01:19:02 GMT

    With the database I use (mainframe network DB) ALL of our batch update
    programs are either:
    1. Journalize the updates along with the existing online transactions.
      or
    2. Back up the database prior to the batch run, run the batch run, and
    backup the database again after the batch run terminates.

    # 2 is allowed ONLY if it is faster than # 1 - NO exceptions.

    (Also, with "my" database, I can back out transactions (using the
    journal files) to a point in time, as well as restore the database and
    re-run the transactions. (Why, as some have asked, do you want/need to
    back out transactions (from a completed/check pointed system? Because
    some dumb **** ran payroll twice. Since I only have time to back up the
    database prior to the start of the online activity in the morning, and
    payroll is run at 8 PM, I do not want to restore the database and re-run
    ALL of the daily online transactions as well as all of the subsequent
    batch transactions until the second payroll job is run.)

    Many modern databases that only "journal" the results of a transaction
    cannot back these transactions out of a completed transaction. It's a
    shame, but we have progressed to the past.

    ***

    Doug Scott wrote:
    > Howard,
    >
    >
    >>Batch is designed to do a lot of
    >>processing at an instant in time. (sure it takes longer
    >>
    >
    > I'm not sure it does. With batch, you usually don't journalise updates
    > (you'd have a single dump/restore point for the entire batch run) so it
    > ought to be a lot quicker if you're selecting by the same criteria.
    >
    > ---
    >
    > Doug
    >
    > dwscott@ieee.org
    >
    >

  • Next message: RH: "Re: Confessions of an "OO Foreigner""