My suggestion is: Don't use DYNAM for compiling CICS COBOL programs. Change your coding standards from:
CALL 'PGM1'. to MOVE 'PGM1' TO CALLED-PROGRAM. CALL CALLED-PROGRAM. With CALLED-PROGRAM being PIC X(8). -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of John Weber > Sent: Thursday, February 16, 2012 10:48 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: CICS vs IMS > > I'm glad the DYNAM/NODYNAM has been brought up. I have a > question about a CICS application. It contains sub modules > using CALL. > > PGM1 (CALL 'PGM2') --> PGM2 (CALL 'PGM3') --> PGM3 > > Each module is translated/pre-processed and then compiled with DYNAM. > > If PGM3 is compiled/linked, then PGM1 and PGM2 must be > re-linked. Can this be avoided? > > Thank you... > > John > > -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John > Sent: Thursday, February 16, 2012 2:01 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: CICS vs IMS > > With the current CICS and COBOL, you must compile your COBOL > with NODYNAM, as I'm sure you know. "static" CALLs in CICS > are still "not supported". However, with LE, it is now > supported to do dynamic CALLs in COBOL. The dynamically > CALLed subroutine still needs to be defined to CICS. The CICS > Language Environment run-time does a CICS LOAD of the > program, then the usual BALR/BASR to actually invoke the > subroutine. The problem that I have with it is that this is > not the equivalent of EXEC CICS LINK. CICS does not "know" > that you've transferred control to a different program. And > so any CICS messages, such as abends, in the CALL'd program > have the name of the last program that was invoked via the > EXEC CICS LINK type interface, instead of the real program name. > > -- > John McKown > Systems Engineer IV > IT > > Administrative Services Group > > HealthMarkets(r) > > 9151 Boulevard 26 * N. Richland Hills * TX 76010 > (817) 255-3225 phone * > john.mck...@healthmarkets.com * www.HealthMarkets.com > > Confidentiality Notice: This e-mail message may contain > confidential or proprietary information. If you are not the > intended recipient, please contact the sender by reply e-mail > and destroy all copies of the original message. > HealthMarkets(r) is the brand name for products underwritten > and issued by the insurance subsidiaries of HealthMarkets, > Inc. -The Chesapeake Life Insurance Company(r), Mid-West > National Life Insurance Company of TennesseeSM and The MEGA > Life and Health Insurance Company.SM > > > > > -----Original Message----- > > From: IBM Mainframe Discussion List > > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Fred Hoffman > > Sent: Wednesday, February 15, 2012 9:35 PM > > To: IBM-MAIN@bama.ua.edu > > Subject: Re: CICS vs IMS > > > > > > They both have their +s and -s, The logging for IMS is very good. > > Easy to use in recovery. I thought that CICS was quicker > and also had > > a pretty good log system. Some of it depends upon the > application you > > are using. I'm a CICS bigot but, I'm also an IMS DBA. > > > > It's you pick and how experienced your staff is. BTW, > calls in cics > > are frowned upon, the last time I checked. > > > > HTH, > > Fred > > > > ________________________________ > > > > From: IBM Mainframe Discussion List on behalf of Roberts, John J > > Sent: Wed 2/15/2012 6:30 PM > > To: IBM-MAIN@bama.ua.edu > > Subject: Re: CICS vs IMS > > > > > > > > >>We are a CICS shop with IMS DB (DBCTL), but I've been > > curious for a while about the differences between how CICS > works >>and > > how IMS TM works. I couldn't find anything on the web. > Anyone have a > > link to a good reference? > > > > Try Google for "IMS DC". The IMS Transaction Manager used to be > > called IMS/DC (for Data Communication). > > > > It has been a long time since I touched it, but my recollection is > > that it was a cleaner implementation within the Operating > System. It > > used CALL level API's (no EXEC IMS > > precompiler) and exploited all the OS capabilities for multitasking > > and multiprocessing. CICS on the other hand tried to isolate apps > > from the OS, becoming its own mini-OS within a single OS address > > space. This was an advantage for CICS back in the 70's. But I > > suspect the table has turned under z/OS. > > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access > instructions, send > > email to lists...@bama.ua.edu with the message: INFO IBM-MAIN > > > > > > > > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access > instructions, send > > email to lists...@bama.ua.edu with the message: INFO IBM-MAIN > > > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access > instructions, send email to lists...@bama.ua.edu with the > message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN