Re: Why separate pools? -- MIDRANGE-L

Simon--

If a program is currently in use, and you recompile the program, you get the new object with the new address. If any process is currently using the old version of the program, the old program is first moved to QRPLOBJ, and the existing process continues to run with the old program. Check the invocation stack and look for programs in library QRPLOBJ (with new system-assigned names). Any new processes get the new program.

This is especially fun with subsystem routing programs. If you recompile a routing program, the old version gets moved to QRPLOBJ. Unless you restart the subsystem (or physically delete the program from QRPLOBJ), the subsystem merrily rolls along using the old version. No matter -how- many times you recompile the program! Ask me how I know! (:

This action of an in-use program being moved to QRPLOBJ brings up one of IBM's "cheats--" IIRC, in the old days of ASPs, you could have libraries in secondary ASPs and programs running from those libraries. If you recompiled the program, the old version still appeared in QRPLOBJ-- in ASP 1-- no matter what library in what ASP it started from! And IBM said it couldn't be done, and wouldn't let mere mortals move things about from ASP to ASP like that!

--Paul E Musselman
PaulMmn@xxxxxxxxxxxxxxxxxxxx


Simon Said (in part):

On OS/400 when you run a program only the first chunk is copied into main storage. If you delete the program from DASD only the current instruction will continue to run. When the system moves to the next instruction it will run into the MCH3402 - Tried to refer to all or part of an object that no longer exists. Therefore one copy of the program. ..... Programs are mostly not "write-capable" but that's not why they get moved. They get moved because there is no lock on them to indicate they may be in use and replacing (i.e., deleting and recreating) will cause jobs using the program to get MCH3402. Try it. You'll have a "learning experience" which is exactly what used to happen on S/38. Recreating an object always results in the new object getting a new address. It never replaces an existing object of the same name and type. Any existing object is either deleted or moved to QRPLOBJ. It is the fact that each object gets a single permanent virtual address that allows the 'move' function to work. The object is not moved, only its context changes.