On May 2, 10:44=A0pm, "Pete Dashwood"
<dashw...@[EMAIL PROTECTED]
> wrote:
> "James J. Gavan" <jgavandeletet...@[EMAIL PROTECTED]
> wrote in
messagenews:RewSj.107=
364$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 =A0<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
particula=
r
> >> 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
sca=
ns
> >> 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
th=
e
> >> 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
need=
s
> >> 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
th=
e
> >> 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
t=
he
> > 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
arri=
ve
> 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
wheth=
er
> 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
th=
e
> >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
w=
as
> > 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
aroun=
d
> > 20-25%, given Internet banking, plus the every increasing volume of
> > debit/credit cards. The current problem is they,(bank data centres),
hav=
e
> > to encode (MICR) the numerals for "Sixty-six dollars and two cents".
Bac=
k
> > 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
o=
f
> > 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 =3D BATCH !
>
> OK, my point was that batch processing will become redundant (largely
> because the processing cycles it consumes will be available in parallel
an=
d
> real time, so they can be applied at the time the transaction occurs,
usin=
g
> distributed parallel processors (which looks like being the next "big
thin=
g"
> 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
leas=
t
> 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. =A0There 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
pape=
r.
> 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
fund=
s
> 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
a=
ll
> 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
sa=
me
> 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.
> I would wager there are people in our
> society now, over 18 and working, who have never seen or handled a
cheque.=
>
> BOTTOM LINE: =A0It won't be fifty years :-)
>
> Pete.
> --
> "I used to write COBOL...now I can do anything."
|
