-----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Michael Knigge Sent: Tuesday, July 07, 2009 5:13 AM To: [email protected] Subject: Question about REUS=NONE
<SNIPPAGE> But I wonder how to migrate the ASM-Subs nearly painless.... I could rewrite all this ASM-Subs and use dynamic Saveareas but I wonder if just using REUS=NONE would do the same job... So bring it to a question: What is the "scope" of the REUS-Option? (Sub)Task-Level? Then using "REUS=NONE" would bring up a new copy of the ASM-Stubs for every Subtask - just what I need.... I don't care for the "wasted" memory because the ASM-Subs are mostly rather small (and well, today they are all statically linked together with some really big COBOL-Subs).... <SNIPPAGE> FIRST: what I am about to say applies to the address space, not just to a specific subtask. The LOAD of a module affects the whole address space, not just a subtask. REUSE=NONE means that every time you issue LOAD you will get a new copy. So if you do multiple LOADs, you will get as many copies as you have issued LOAD for. This will result in BTL (Below The Line) storage "creep" because of the system control blocks that are built in LSQA, which means that you might take a short on storage ABEND if you are not also issuing "DELETE" for the module. IF you use REUSE, or RENT, AND the ASM stubs are actually ReENTrant, you MAY care if you are not also issuing "DELETE", because only one copy will get loaded, but each subsequent LOAD will result in the use count being incremented by 1 (DELETE decrements by 1). When the count rolls over, you will ABEND. If you do LINK with REUSE or RENT and those stubs are not actually Reentrant (or effect serial reusability), results will probably be unpredictable -- the assumption being that the DSA within the program is "YOUR" DSA (your "return registers"), but meanwhile, your task has not been dispatched while another has, so that when you start dispatching again, where you return to... I hope this answers your questions. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those held by poster's employer. -- ---------------------------------------------------------------------- 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
