Macro code was deprecated with CICS 1.5 in the early 80s, though it stayed around for many years after that.
On Wed, Jul 26, 2023 at 9:39 AM Pommier, Rex <[email protected]> wrote: > 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 <[email protected]> On Behalf > Of Crawford Robert C (Contractor) > Sent: Wednesday, July 26, 2023 9:26 AM > To: [email protected] > 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 <[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://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 [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 > > ---------------------------------------------------------------------- > 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 [email protected] with the message: INFO IBM-MAIN > -- Jay Maynard ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
