The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main as well.
[email protected] (Brendan Friel) writes: > 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). re: http://www.garlic.com/~lynn/2009i.html#21 Why are z/OS people reluctant to use z/OS UNIX? in the 90s period, the "overnight batch window" was experiencing severe strain, in part because of business growth was increasing the work that had to be done in the window and some amount of globalization was decreasing the size of the window ... as well as increasing the amount of work. when we were doing (our/)ibm's ha/cmp product ... some reference http://www-03.ibm.com/systems/power/software/availability/aix/index.html we went into siac several times to talk about thier (trading) operation. we also had this Jan92 meeting on ha/cmp scaleup http://www.garlic.com/~lynn/95.html#13 in fact, my choice of product name "ha/cmp" ... reflected all the work we had been doing for cluster scaleup ... some old email http://www.garlic.com/~lynn/lhwemail.html#medusa but then that part of the effort got transferred (and announced as a numerical intensive product) and we were told to not work on anything with more than four processors (however, the ha/cmp seem to stick). shortly after that, we decided to leave. somewhat related recent post (mentions that long ago and far away my wife had been con'ed into going to POK to be in charge of mainframe loosely-coupled architecture) http://www.garlic.com/~lynn/2009h.html#1 z/Journal Does it Again now two of the other people that were also in that Jan92 meeting, moved on to a small client/server startup and we brought in as consultants because they wanted to do payment transactions on their server. The small client/server startup had also invented this technology called "SSL" which they wanted to use ... in any case, that work is now frequently called "electronic commerce". In the mid-90s, somewhat as a result of the "electronic commerce" work, we were invited to particate in the x9a10 financial standard working group which had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments (i.e. *ALL* as in *ALL*, POS, internet, debit, credit, stored value, unattended, face-to-face, transit turnstyle, etc, i.e. *ALL*). We did some detailed threat and vulnerability studies and eventually came up with x9.59 retail financial standard transaction protocol ... some references http://www.garlic.com/~lynn/x959.html#x959 somewhat as a result of the electronic commerce and x9.59 work, we were invited into NSCC (since merged with DTC for DTCC) to look at doing something similar for all trading operations. After a short while, the work was suspended ... possibly because a side effort would have been significantly increased transparency and visibility ... which apparently wasn't naturally part of trader culture. note in the recent congressional hearings into the Madoff Ponzi scheme, a reoccuring theme by the person that had been trying for a decade to get SEC to do something about Madoff ... was that much more important than new regulations is the requirement for transparency and visibility. -- 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
