CICS was "common code" between VS1 and DOS/VS(E) DOS/VS (I used to build it for CICS development), with AIF.. ANOP statements around VS1/DOS specific code. DOS/VS did not have the same facilities as VS1, so CICS had to be written to the lowest level of code.
On Wed, 26 Jul 2023 at 14:45, Crawford Robert C (Contractor) < 000004e08f385650-dmarc-requ...@listserv.ua.edu> wrote: > Yes, CICS has problems with shared memory which it mitigates through > storage protection and transaction isolation. IMS MPR's are not entirely > immune from this either as a bad array index or funky pointer can wipe out > acres of storage and leave a region inoperative. I saw some MPR loops that > were so tight all we could do is put the address space in a WLM penalty box > and bring down the control region at night. > > I also remember that canceling an MPR was always a last resort because, if > the interface was in the wrong state, it could bring down the control > region. > > CICS has had open TCB's for decades now that enable application programs > to use any old OS interface they want. Global User Exits (GLUE's) provide > clean interfaces for all sorts of system software and DBMS' . > > When I worked in an IMS dominated shop we always had to carefully watch > CSA and ECSA. Sure, CICS regions can use a lot of memory, but you can > always buy more real storage. > > MPR's, which I saw implemented as batch jobs, do provide great isolation > between processes and allow for exploitation of OS services. CICS > duplicates a lot of OS services but why have a storage manager on top of a > storage manager? On the other hand, keeping things going smoothly means > running dozens, if not hundreds, of MPR's to support a transaction rate > that could be executed by a fourth as many CICS regions. > > MPR's are basically batch jobs getting fed one message at a time. This > implementation requires a lot of bolt-ons (e.g., IMS Connect) which come > with their own quirks. I've also seen it require weird solutions for > fitting synchronous processes to an asynchronous system. > > I did like MFS because it provides true device independence. It allowed > us to drive 3270 transactions with LU6.1 messages from CICS without any > changes. > > I could also go on about dynamic resource definition, automated emergency > restart (without using automation), better system management interfaces. > Not to mention quicker, cleaner and native implementations of newer > technologies. > > IMO, CICS is much more flexible and better positioned to continue > processing in the modern world. > > Robert Crawford > Abstract Evolutions LLC > (210) 913-3822 > > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf > Of Schmitt, Michael > Sent: Tuesday, July 25, 2023 9:38 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why it > survives > > So CICS is no longer doing cooperative multitasking within each AOR, and > thus requiring CICS versions of OS commands to prevent wait states from > freezing the entire AOR? A CICS program can do direct GETMAINs, LOADS, > abends, rather than use CICS commands? CICS no longer requires special > versions of tools (e.g. debugger, abend dump management) and instead can > use the same tools as batch programs? A CICS programmer no longer needs to > learn a long list of CICS commands and EXEC CICS syntax? A CICS region no > longer contains the storage from all of the transactions currently running > and is now only one transaction in the region at a time? CICS transactions > can no longer stomp on each other's memory? > > Great, I did not know that. > > IMS/TM uses the operating system for multitasking. There are no IMS/TM > specific tools. An IMS/TM programmer only needs to know two commands, one > to get a message and another to send it. IMS transaction abends look > (almost) exactly like a batch abend. IMS programs have no restrictions on > OS facilities. An IMS program can even do an STIMER (WAIT) without > affecting any other transaction processing. Because, it uses the OS to do > *preemptive* multitasking, like a modern operating system. > > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf > Of Crawford Robert C (Contractor) > Sent: Tuesday, July 25, 2023 8:14 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why it > survives > > Sorry, I worked in a shop that had both and I can tell you CICS is way > more flexible, modern and performed better. > > I will give you this: IMS is a great piece of 90's technology. > > Robert Crawford > Abstract Evolutions LLC > (210) 913-3822 > > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf > Of Schmitt, Michael > Sent: Monday, July 24, 2023 11:43 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXT] Ars Technica: The IBM mainframe: How it runs and why it > survives > > Ars Technica published a deep-dive explainer of modern IBM mainframes: > > > https://arstechnica.com/information-technology/2023/07/the-ibm-mainframe-how-it-runs-and-why-it-survives/ > > > Iād quibble with the application server topic that talks about CICS with > no mention of IMS/TM. CICS is to IMS as Windows 3.1 is to Windows 10. š > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
