On 28 Apr 2010 12:18:47 -0700, in bit.listserv.ibm-main you wrote: >About mainframe business applications, Zman writes: > >| OK, but if they work, they're "good enough". Sure, you >| and I would be itching to 'fix' them, but that's an urge we | should resist. > >I disagree. > >My own experience of these applications has been different. Most do "work", >in the sense that they get some useful processing done; but this is the only >favorable thing that it occurs to me to say about them: > >o In most shops more resources are devoted to routine, trivial maintenance, >accomplished ad hoc, than to either new-system development or significant >system extensions; > >o They employ obsolete compile-time bound, move-orient[at]ed, synchronous >technology that pours concrete over their company's business plans;
Many of the systems still really date back to the 1960's where the limitations of the time meant far more compile time freezing as opposed to run time. > >o They are radically inflexible, full of ad hoc "design' limitations that >permit them to take cognizance of at most 4 or 7 widgets, at most 6 gidgets, >and the like; > >o They have not been designed; they are radically incoherent because bits and >pieces of them have evolved in many different directions under many disparate >impeti; > >o They reflect no understanding of the distinction between functional >requirements and processing strategies, of the notion that requirements do not >dictate implementations; > >o Qua programs, they are disasters: one of the founding fathers observed long >ago that COBOL programmers could in his experience be divided into two >disjoint subsets, there were those, a moiety, who did not know what binary >search was and then there were those few who did and were pround of this >arcane knowledge; and this situation is little changed today; Getting a sorted table from input if the input isn't already sorted requires one to either know sorting techniques or use the SORT verb. SEARCH ALL (more efficient, usually binary but up to the implementer) came in with the 1974 standard but did require someone to know what they were doing. I was not impressed with the implementation in COBOL 74 and don't recall checking the generated code to see if COBOL II or COBOL for MVS and VM improved it. At one shop, programming was on the rotation for accounting and marketing types. > >o IT management is technically ill-informed, petulant, and risk-aversive. The first and third can be true (especially the third) if the management comes from outside IT. > >Fatuous defense of what is will not save the platform. Nor will crackpot >realism of the if-it-isn't-broken-don't-fix-it sort. > >What is worse is that moving to another environment will not usually help >either. The same people will replicate the same ills in it. If most of the problem is management and management attitude, platform change may cure it by fiasco. More dangerous are those who still believe sales people implicitly. > >John Gilmore Ashland, MA 01721-1817 USA > > > >_________________________________________________________________ >The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with >Hotmail. >http://www.windowslive.com/campaign/thenewbusy?tile=multicalendar&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5 > >---------------------------------------------------------------------- >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 ---------------------------------------------------------------------- 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
