Re: Why separate pools?

[Neil Palmer/DPS <neilp@xxxxxxxxxxx>]

Was there ever a fix for when a still running is moved to QRPLOBJ and 
tries to sent a msg to the program message queue - which fails because it 
had been renamed ?

...Neil




PaulMmn <PaulMmn@xxxxxxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
2004/11/25 12:02



To
Simon Coulter <shc@xxxxxxxxxxxxxxxxx>
cc
midrange-l@xxxxxxxxxxxx
Subject
Re: Why separate pools?






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.
--