And then there's this handy little tool from MacKinney systems called MLI that allows macro level code to still run in 2023! Was macro code deprecated around 1988?
Rex -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Crawford Robert C (Contractor) Sent: Wednesday, July 26, 2023 9:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: [EXT] Ars Technica: The IBM mainframe: How it runs and why it survives 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 <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Colin Paice Sent: Wednesday, July 26, 2023 8:57 AM To: IBM-MAIN@LISTSERV.UA.EDU 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) < 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://urldefense.com/v3/__https://arstechnica.com/information-techno > logy/2023/07/the-ibm-mainfra__;!!KjMRP1Ixj6eLE0Fj!rNa-SaGicFiF68vSt9OY > ExPvljK4ShqzUuxW9fAMxwJNqupUj5wjtWSiwuUmUuPL5Zz9fb1K1RGcyBzezNfMZS69W9 > lqPfp6mPyI$ > 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 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
