IMS/DB vs most other databases? Having worked with IMS/DB and DC and CICS with a variety of DBMS, I'd venture that CICS offers way more flexibility. For example, I've worked in CICS shops with ADABAS, DATACOM, TOTAL, DB2, not to mention that many of the 4GL products were tailored to work in a CICS environment. DOS and DOS/VSE had the ability to run CICS with a third party DBMS such as DATACOM or ADABAS.
I did appreciate the simplicity of IMS DB and DC from a programming perspective, however, the navigation of IMS/DB allows a mess of methods to get to the pertinent data. How do you find a segment? Easy just GN till you find it :) At some point you could just use a single segment database and pretend it's relational with enough indexes. MFS paging was perhaps "better" than BMS paging. I used the technique once, it was simple to program but response time was extremely bad for large data sets. On Thu, Jul 27, 2023 at 3:05 AM Pommier, Rex <[email protected]> wrote: > This product is strictly for maintaining the old macro programs. It works > well and silently in the background, allowing us to keep running macro > level code. The only problems we had have been at upgrade time. When we > went to CICS 5.3 and again to 5.6, we had to have MacKinney refit MLI to > the new CICS level. > > Rex > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On Behalf > Of Crawford Robert C (Contractor) > Sent: Wednesday, July 26, 2023 10:37 AM > To: [email protected] > Subject: Re: [EXTERNAL] Re: [EXT] Ars Technica: The IBM mainframe: How it > runs and why it survives > > Oh man, I feel your pain. > > I looked at the FAQ for the product. Does MacKinney provide means to > update the programs or does the customer have to keep the old macro level > translator around? > > Robert Crawford > Abstract Evolutions LLC > (210) 913-3822 > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On Behalf > Of Pommier, Rex > Sent: Wednesday, July 26, 2023 10:23 AM > To: [email protected] > Subject: Re: [EXTERNAL] Re: [EXT] Ars Technica: The IBM mainframe: How it > runs and why it survives > > "potential"? :-) > > Rex > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On Behalf > Of Crawford Robert C (Contractor) > Sent: Wednesday, July 26, 2023 9:57 AM > To: [email protected] > Subject: Re: [EXTERNAL] Re: [EXT] Ars Technica: The IBM mainframe: How it > runs and why it survives > > I don't remember the specific date. I think CICS 3.2.1 was the last > release that supported it. > > Fortunately, we only had to run CICS 3.2.1 and CICS 3.3 in parallel for a > few months. I'm glad our application guys didn't know about MLI. It > sounds like a transition tool that has the potential to turn into a > permanent solution. > > Robert Crawford > Abstract Evolutions LLC > (210) 913-3822 > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On Behalf > Of Pommier, Rex > Sent: Wednesday, July 26, 2023 9:39 AM > To: [email protected] > Subject: Re: [EXTERNAL] Re: [EXT] Ars Technica: The IBM mainframe: How it > runs and why it survives > > 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 > > ---------------------------------------------------------------------- > 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 > > ---------------------------------------------------------------------- > 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 > -- Wayne V. Bickerdike ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
