On Fri, Mar 9, 2012 at 6:46 AM, Farley, Peter x23353 <peter.far...@broadridge.com> wrote: > Tim, > > In one of your replies over on the CICS-L list you gave this reasoning for > the design decision to use static inclusion of this "common" module: > > "Just some background on why the static call to BA4C1426 was done in the > first place. This COBOL application is proprietary object-oriented > programming (or as I like to call it obfuscation-oriented programming). So > the BA4C1426 is the main data structure class that is a doubly linked list. > So almost every class uses it, and to improve on performance they statically > linked it into almost all of the classes." > > I would first question the application designers' original decision to > statically include this module for performance reasons. Did they actually > measure the difference between static inclusion and dynamic calls to an > external version of that data structure subroutine? My (admittedly limited) > understanding of the LE dynamic CALL mechanism is that reentrant dynamically > CALLed modules are loaded only once and thereafter branched to directly > (which obviously does include some LE overhead, but my unproved suspicion is > that this LE overhead is quite small).
I'm guessing they measured again the COBOL dynamic call facility. Based on current experience their is significant overhead associated with the COBOL dynamic call facility as well as the C runtime program fetch facility. In both cases significant performance advantages can be gained by creating a small assembler program to LOAD/DELETE the desired module. In COBOL, the address of the LOADed module can be saved a variable defined as USAGE FUNCTION-POINTER. This allows a normal COBOL CALL statement to be used. In C just save the address of the loaded module in a variable defined as a function pointer. If the shop does not want to write their own load routine, LE provides several facilities (ceeplod, ceeplod2 and ceeplodt) depending on the requirements. > > Considering that an OO COBOL module is almost certainly eligible to be > compiled RENT and linked RENT,REUS,REFR, that means only one copy of the > module resident for all callers, no matter how many there are. The current > application design ensures that in fact there are 11,000+ copies of this > module, one in each other program that includes it. As you have discovered, > this is a maintenance nightmare when the common module needs to change for > any reason. > > If someone were to write a "driver" routine for this data structure > subroutine to test all of its functions in a parameterized loop, then one > could run two versions of that "driver" module, one statically linked and one > using dynamic CALL and have the "driver" module exercise all the functions of > the common module several hundreds of thousands or even millions of times to > actually measure the performance difference. > > Then you would have actual data on which to base a decision. > > Just my USD$0.02 worth from the applications design and maintenance point of > view. > > HTH > > Peter > >> -----Original Message----- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On >> Behalf Of Tim Zielke >> Sent: Thursday, March 08, 2012 12:50 PM >> To: IBM-MAIN@bama.ua.edu >> Subject: Re: JCL example to relink a CSECT into an existing load module >> >> This would require a recompile of pretty much the entire application which >> is around 11,000 load modules. This COBOL application is written in >> proprietary object oriented COBOL and each load module represents an >> object oriented class (for the most part). So a recompile of the entire >> application would require a testing/migration effort that is too arduous >> for the application team. >> >> However, if we can just change the statically compiled BA4C1426 program >> and relink it into the existing 11,000 load modules, it significantly >> reduces the scope of the change to something that is more manageable from >> a testing and migration effort. >> >> Thanks, >> Tim Zielke >> CICS/MQ Systems Programmer >> Aon Hewitt > -- > > > This message and any attachments are intended only for the use of the > addressee and may contain information that is privileged and confidential. If > the reader of the message is not the intended recipient or an authorized > representative of the intended recipient, you are hereby notified that any > dissemination of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by e-mail > and delete the message and any attachments from your system. > > ---------------------------------------------------------------------- > 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
