It's interesting to link (trade) settlements to overnight batch COBOL.
That's not really an option(sic) in today's trading world - you need to support same day settlements and various intraday business functions. This type of need would be reflected in a multitude of business functions across various industries that need real time (or close to real time) updates, and that historically used the 'key in during the day - run batch updates at night' model. (There are still tons of apps that are using this model successfully because it supports their business functions). That doesn't rule out mainframe COBOL at all - any mainstream Java/.NET or other mainstream web based architecture will support calling COBOL/DB2 stored procedures. 'During the day' batch jobs using COBOL can be scheduled to augment the SP processing if necessary. This model works like a champ and will usually allow for major reuse of legacy COBOL code. XML can be used as a common format to transfer data between platforms. Cheers, Brendan > Date: Thu, 4 Jun 2009 08:27:43 -0400 > From: [email protected] > Subject: Re: Why are z/OS people reluctant to use z/OS UNIX? > To: [email protected] > > The following message is a courtesy copy of an article > that has been posted to bit.listserv.ibm-main as well. > > > [email protected] (Barbara Nitz) writes: > > My point of contention is that most of the 'programmers' (That's why I > > called > > that 'clicking') don't care that their code is poor. My neighbour - a nice > > young > > man of 25, just finished his IT-education, and he is sharp! - stated the > > mind > > set of those I call 'clickers': "If it works on my PC, I don't care if it > > has a > > performance problem in production. Someone else in the project hierarchy > > has > > to fix it." (like the architect for the project or the customer). With this > > attitude, about 99% of the 'ported' code is really bad for the environment > > it is > > supposed to run in productively. And the 1% that isn't so bad has a lot of > > customer blood attached to it. > > recent references to billions spent (mostly by financial industry) on > failed attempts to leverage large farms of PCs to implement "straight > through transaction" processing in the 90s ... as alternative to > (mostly) large cobol batch processing that ran in "overnight batch > windows" doing things like settlement to complete online transactions > that had occured during the day. > > the issue was that some number of them got past the pilot stage and into > full scale deployment before the scale-up issues appeared on their > horizon. it turns out that implementations were doing things that > resulted in 100 times bloat in the implementation (compared to the batch > cobol) ... totally swamping any anticipated through-put improvements > from using large PC farms. > > http://www.garlic.com/~lynn/2009.html#87 Cleaning Up Spaghetti Code vs. > Getting Rid of It > http://www.garlic.com/~lynn/2009c.html#43 Business process re-engineering > http://www.garlic.com/~lynn/2009d.html#14 Legacy clearing threat to OTC > derivatives warns State Street > http://www.garlic.com/~lynn/2009f.html#55 Cobol hits 50 and keeps counting > http://www.garlic.com/~lynn/2009h.html#1 z/Journal Does it Again > http://www.garlic.com/~lynn/2009h.html#2 z/Journal Does it Again > > -- > 40+yrs virtualization experience (since Jan68), online at home since Mar1970 > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html _________________________________________________________________ Lauren found her dream laptop. Find the PC that’s right for you. http://www.microsoft.com/windows/choosepc/?ocid=ftp_val_wl_290 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
