johnwgilmore0...@gmail.com (John Gilmore) writes: > The original design of CICS envisaged making elegant use of the > announced facilities of OS/MVT. When the time came to implement CICS > 1) some of these facilities were not yet available and 2) some of them > did not yet work reliably. The implementers of CICS were thus forced > to take a RYO approach. They in effect gutted an MFT partition and > installed their own functionally MVT-like facilities in it, calling > their storage-management interfacing macros GETMAIN and FREEMAIN, > etc., etc. > > The result was an in many ways a superb table-driven system, one that > improved significantly over the succeeding years. Its chief 'defect' > was the implementation of its user interfaces as a set of > assembly-language macros, which meant that applications run under it > had to be written in assembly language. This was 'remedied' in > various ways, some elegant and some not, and finally by introducing a > 'command'---as opposed to the old 'macro'---level CICS; ultimately it > became possible to write CICS APs even in RPG, although these could > not be even quasi-reentrant. > > The major marketing obstacles to its use by other than > assembly-language programmers were thus gradually removed. > > In my own doubtless élitist view CICS never fully recovered from these > initiatives. They did enable ribbon clerks to write CICS APs, and > opinions about whether that was beneficial differ widely. > > What is not in my view open to argument is that criticism of the > present state of CICS and other such subsystems that is not diachronic > is all but certain to be irrelevant. > > We are all, ineluctably, creatures of our experience. If you don't > know the history of CICS, IMS, DB2, whatever, mug it up if you wish to > discuss that subsystem; and stai zitt' until you have mastered it. > (Controversy will not thus be eliminated or perhaps even much reduced; > equally informed views can, do differ sharply; quaint irrelevance will > be reduced).
I've more characterized that pathlengths for os/360 was so enormous that there was no way to do light-weight operations. CICS effectively batched a large percentage of os/360 operations at startup ... and then used its own lightweight versions for actual operation. Disclaimer: Univ library got ONR grant to do online catalog and used part of the funds to get 2321 datacell. It was also selected for one of the beta test sites for CICS program product (1969) ... and I got tasked for supporting & debugging the deployment. Part of the CICS birthing experience was shooting some number of bugs related to the library choosing different BDAM options than the site where CICS was originally developed. misc. past posts mentioning CICS &/or BDAM http://www.garlic.com/~lynn/submain.html#cics other cics history (gone 404 but lives on at the wayback machine): http://web.archive.org/web/20080123061613/http://www.yelavich.com/history/toc.htm The Evolution of CICS: CICS Services for Performance (1968) http://web.archive.org/web/20060325095459/http://www.yelavich.com/history/ev196805.htm from above: In the very beginning, CICS attempted to use services provided by the operating system(s) (PCP, MFT and MVT), however it quickly proved to be unacceptable because of the relatively high overhead of those services (CPU cycles and storage consumed with regard to the particular service). ... snip ... I've made similar claims (about large part of design involved countermeasures for heavyweight os/360 services) ... old email Jim Gray wanting me to be take responsibility for consulting with the IMS group when he was leaving for Tandem: http://www.garlic.com/~lynn/2007.html#email8011016 IMS wiki http://en.wikipedia.org/wiki/IBM_Information_Management_System as to DB2 ... original relational/sql was done at sjr on vm370 some number of past posts http://www.garlic.com/~lynn/submain.html#systemr the standard folklore was that we were able to do tech. transfer from sjr to endicott for sql/ds "under the radar" when the corporation was distracted with the official DBMS product, EAGLE. Then when EAGLE imploded, there was a request about how fast could there be a port to MVS ... eventually turning into DB2. for random other DB2 lore ... one of the people mentioned in this Jan92 meeting in Ellison's conference room claims to have done the SQL/DS transfer from Endicott back to STL http://www.garlic.com/~lynn/95.html#13 ... separate from the SJR work. Additional relational/SQL lore: http://www.mcjones.org/System_R/SQL_Reunion_95/index.html -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
