imugz...@gmail.com (Itschak Mugzach) writes: > Interesting. If Cobol would be a problem, I would expect most of IBM > mainframe shops to develop new applications in (so called) modern languages. > I don't see it here in Israel. Most of the new code is still developed in > Cobol, Natural and some PL/I. farther more, if you are a mainframe centric > shop, it would be so cleaver to distribute your applications when everybody > is doing the opposite (server consolidation, green computing, etc.). What I > do see is a movement from direct coding to rule engines and code generators. > At end, programming will be like tailoring. Experts will develop the rules, > and the programmer will just drive the records in and our invoking the > rules. > > As other wrote, Cobol is just another language in the forest, an easier one > to understand.
re: http://www.garlic.com/~lynn/2010h.html#46 COBOL - no longer being taught - is a problem there was big push in the 90s to re-engineer a lot of legacy financial applications (large percentage cobal) that were running settlement batch applications running overnight; using new languages, new processes, large numbers of "killer micros" and parallel operation ... in order to have "straight through" processing (eliminating overnight batch settlement for transactions). the toy demos looked good but things collapsed when it came to production rollout. they had ignored speeds&feeds and the technology used had something like 100 times more overhead than the batch cobol (totally swamping any anticipated increased thruput from large numbers of killer micros). In the past decade, I've done some consulting with company that has developed an infrastructure that translates high-level financial business rules into fine-grain SQL transactions. they've been able to demo rapid development/deployment of straight through processing ... with highly parallelized and very high transaction rates. A primary difference compared to the 90s efforts ... is that they rely on the significant parallel technology that has been developed by RDBMS vendors (rather than trying to invent everything from scratch). The parallel RDBMS implementation may have 4-5 times the overhead compared to non-parallelized/sequential batch cobol with vsam ... but the real-time thruput is significantly increased with parallel operation (able to accomplish straight through processing and eliminate the overnight batch settlement). -- 42yrs virtualization experience (since Jan68), online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
