> -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Leslie Wagner > Sent: Monday, May 04, 2009 10:09 AM > To: [email protected] > Subject: Re: Assembler and ECBL conversion issues > > I am the original poster of this on bit.listserv.ibm-main. PJ Farley ccd > it here - thanks Pete!
You're quite welcome. Glad to help. > These assembler modules all do I/O against VSAM and QSAM files. Open, > close, gencb, modcb, acb macros mostly that I've seen so far. I'm still > going thru them. > > Some of them were upgraded from older DOS assembler code 37 years ago or > so. I think we want to take the path of least resistance here, but also > wanted to know just what we might be losing by taking that path. Well, if they're mostly I/O subs you may want to replace them eventually, but for the "least resistance" path you can just leave them alone for now and try the "helper module" route I suggested in my first reply. As to what you lose, you can safely assume that the Enterprise COBOL code will occupy more storage than the older COBOL II code, if for no other reason than that Enterprise COBOL uses re-entrant working-storage where VALUE clauses mean that variables are initialized with actual code on first entry rather than just meaning data is compiled into the object code. So keeping the new Enterprise code below the line will result in even less available storage than the current COBOL II code has. As I said earlier, a generic helper module that could call any of these 24-bit modules (LE-enabled assembler or even a COBOL version) would give you breathing room if you can nail down all the possible parameters. Then you can use DATA(31) for all your Enterprise COBOL recompiles and get at least some of the advantages of the conversion right away. BTW, using DATA(24) does not require static links. The simple change to dynamic call instead of static can be combined with DATA(24), so that your new COBOL code resides above the line even if your data is below. OTOH, static links mean lower CALL overhead, so CPU usage may well increase a bit for dynamically-invoked subroutines. If you go the helper module route, that module should be linked AMODE(31)/RMODE(ANY) (and DATA(24) if COBOL) and use dynamic CALL to the assembler subroutines. On the third hand, you really do want to try to avoid the DATA(24)/static link solution if at all possible. IMHO it's the worst of all possible worlds. If you're already managing re-links when a subroutine changes (or if they never do change), I guess I can see a management decision to avoid the work, but only if there is a follow-on plan (with an allocated budget!) to finish the upgrade to get to a full DATA(31) environment in reasonably-sized phases. Feel free to ask more questions as they come up. Regards, Peter 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 [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
