"Richard" <riplin@[EMAIL PROTECTED]
> wrote in message
news:2db5bfab-5d42-4a26-af71-695e3cf8f93a@[EMAIL PROTECTED]
May 2, 10:44 pm, "Pete Dashwood"
<dashw...@[EMAIL PROTECTED]
> wrote:
> "James J. Gavan" <jgavandeletet...@[EMAIL PROTECTED]
> wrote in
> messagenews:RewSj.107364$rd2.67172@[EMAIL PROTECTED]
>
>
>
> > Pete Dashwood wrote:
> >> <docdw...@[EMAIL PROTECTED]
> wrote in message
> >>news:fvcpf4$ge8$1@[EMAIL PROTECTED]
>
> >>>In article <6cnj14db0cpscakdtdacpotptrgtjnk...@[EMAIL PROTECTED]
>,
> >>>Howard Brazee <how...@[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 re****ts. (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 re****ting 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 re****ts that are based around
a
> >> time series, for example, and the data for each line of the re****t
> >> 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 re****t" was viewed as a
re****t
> >> "object" with a "collection" of re****t 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
re****t
> >> 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 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...)
>
> > You make it sound so easy, if you leave pertinent bits out.
>
> What pertinent bit do you believe was left out, Jimmy?
>
> > All fine and dandy above, but all your elements in the Collection, and
> > the
> > Collection itself, are NON-PERSISTENT objects, in memory as
vapourware.
>
> Only very briefly until they are stored. What's im****tant, and the point
I
> was trying to make, is that by thinking about it differently, you can
> arrive
> at a different solution.
>
> Sure, the objects are volatile if you are talking about OO processing.
I'm
> talking about OO concepts, not the programming level. The collection of
> re****t lines is "viewed as" a collection (I did say that...)
conceptually.
> Of course it has to be stored somewhere and it is totally irrelevant
> whether
> you use an object storage system or a standard RDB.
>
> >Theoretically it could work, providing you don't exit the application
or
> >somebody pulls the wall-plug. For security's sake you would have to
store
> >the elements as PERSISTENT objects in text form in a file or DB. When
> >appropriate you could read the Persistent DB Table and either recreate
> >the
> >Collection for re****ting or print direct from the DB.
>
> There you go... :-) (That's not the only way to do it, BTW...)
>
>
>
> > I can't see 'batch processing' entirely disappearing - not in the
first
> > half of this century, anyway. I mentioned some years back a friend who
> > was
> > the night-time supervisor for a bank data centre in Calgary;
collecting
> > ALL cheques for Alberta, parts of North West B.C and a little of
> > Saskatchewan, on our eastern border. (Their cut-off was something like
> > 02:00 hours to get the encoded batches back East (Ontario)).
>
> > During her tenure volumes decreased to 30% and most likely are now
> > around
> > 20-25%, given Internet banking, plus the every increasing volume of
> > debit/credit cards. The current problem is they,(bank data centres),
> > have
> > to encode (MICR) the numerals for "Sixty-six dollars and two cents".
> > Back
> > in 1967 OCR was a challenge and still IS - there's no way, other than
> > universal draconian legislation, to make humans all write their
numbers
> > in
> > a set format. (The way you and I write the Arabic numeral 'five' is
not
> > the way an Egyptian writes it).
>
> > Some years back I did read where software had been written to
recognise
> > Chinese characters and that Microsoft was interested. So in due course
> > of
> > time if there's an enhanced OCR, which can read the Rosetta Stone then
> > banks wont be faced with the manual intervention of keying in MICR.
> > Nonetheless, however the cheques are encoded you are still left with a
> > bunch of cheques = BATCH !
>
> OK, my point was that batch processing will become redundant (largely
> because the processing cycles it consumes will be available in parallel
> and
> real time, so they can be applied at the time the transaction occurs,
> using
> distributed parallel processors (which looks like being the next "big
> thing"
> to hit IT, and will change some of the ways we look at programming...))
>
> Taking your example of the Bank above, I hope you would agree that if
> cheques are eliminated, so is that particular problem.
>
> I believe they will be. (I haven't personally written a cheque for at
> least
> 15 years now and I haven't seen one for at least five years. (NZ is very
> much an electronic society so we may be atypical.) Even if they
(cheques)
> are not eliminated, MICR encoding is pretty archaic. Leaps have been
made
> in
> OCR techology and recognition software generally. There are systems now
> that can recognises faces from moving video, shot at a distance in poor
> light; deciphering numbers is unlikely to be a problem.
>
> A truly illegible cheque won't make it into the system anyway.
>
> Online banking means not sending money through the mail as a piece of
> paper.
> I pay regular bills by standing orders or direct debits, and one offs by
> electronic transfer, initiated from my Notebook computer, direct to the
> recipient's bank account. (I bought something on "TradeMe" (NZ
equivalent
> of
> e-bay) in exactly this way, just a few days ago. Completely painless...
a
> vendor in Wellington 300 miles away received my electronic transfer into
> their account overnight and I had the goods (sent by courier once the
> funds
> were in the bank), before the end of the same day.)
>
> Both my company and personal income is all electronic. I can't speak for
> all
> New Zealanders, but I'm pretty sure most of us no longer carry more than
a
> few dollars in cash, never mind cheque books. We use EFTPOS (Electronic
> Funds Transfer at Point Of Sale) in more than 90% of businesses and the
> same
> system allows credit and debit cards.
I use cash and cheques. I have never once used EFTPOS and have used my
credit card locally perhaps 4 times in the last 10 years. I do use it
for overseas stuff. The wife does use credit cards but it is always
paid off every month. When clients ask for my bank details to do
direct credit I 'lose' the paperwork and then eventually send a
cheque.
One complains that the have to keep a cheque printer around just for
me, having now given up on trying to do it another way.
I do use ATMs, however, but distrust them.
[Pete]
Thanks for that Richard. Your post prompted me to survey some other
friends.
I talked to 6. 2 of them are under thirty and would not even consider
using
cheques, seeing them as "quaint" :-) The three over 50 all have cheque
books
(I don't myself), but only one of them uses it regularly.
The remaining one reckoned she never pays bills anyway and if she needs
anything she steals it from the Warehouse... :-) (She had had a few drinks
and I saw no point in pursuing a serious discussion :-))
I think my perception may have been wrong and more people actually use
cheques and cash than I thought. Certainly the older folks said they
objected to EFTPOS because it was hard enough to remember a pin for ATMs
without having another one as well...
> I would wager there are people in our
> society now, over 18 and working, who have never seen or handled a
cheque.
>
> BOTTOM LINE: It won't be fifty years :-)
>
> Pete.
> --
> "I used to write COBOL...now I can do anything."
|
