That's good to know. I always assumed CICS had a storage manager because it was faster than GETMAIN/FREEMAIN.
I remember the old macro interface and it was a mess, especially with application programs addressing system control blocks directly. Not to mention how weird macro code looked in the middle of a PL/1 program. IBM was wise to deprecate the interface even though the conversion caused pain. Robert Crawford Abstract Evolutions LLC (210) 913-3822 -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Colin Paice Sent: Wednesday, July 26, 2023 8:57 AM To: [email protected] Subject: Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why it survives 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) < [email protected]> 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 <[email protected]> On > Behalf Of Schmitt, Michael > Sent: Tuesday, July 25, 2023 9:38 AM > To: [email protected] > 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 <[email protected]> On > Behalf Of Crawford Robert C (Contractor) > Sent: Tuesday, July 25, 2023 8:14 AM > To: [email protected] > 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 <[email protected]> On > Behalf Of Schmitt, Michael > Sent: Monday, July 24, 2023 11:43 AM > To: [email protected] > 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-mainfra > me-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 [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to [email protected] with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
