Re: Using QRPLOBJ Library

[CRPence <CRPbottle@xxxxxxxxx>]

  AFaIK there is little special magic [beyond what one could 
implement as a user of the OS] with how REPLACE(*YES) processing 
functions.  As I understand the feature, there is an optional RNMOBJ 
and then a MOVOBJ into the QRPLOBJ library; similarly for how the 
PTF process replaces an object, except with that there is some 
special processing at least for Message Handling.  If a process had 
previously resolved\located from the original library, the 
since-moved object, then all references to that object by address 
versus by re-resolving the name-to-its-address in that process can 
[in general] continue to use the object in QRPLOBJ as though nothing 
changed.  Potential difficulties may exist for code which asks the 
question about "what is the name or location of the object addressed 
by that previously resolved pointer?", if\when that code then uses 
the answer to that question in order to make decisions about what to 
do; e.g. the following assumption about a program name matching a 
known literal, when the new name has become 'MYPGM00005QRPLOBJ   ', 
might cause problems for the following pseudo-code: if 
WhoCalled()='MYPGM_NAMEMYLIBRNAME' then DoStuff().

  So for an already resolved program:
   - If the CALL interface is via pointer, then future invocations 
can continue to use the object at the same\original address; i.e. 
the object which is now in a different library and possibly with a 
different name, still and always will have the same address.
   - If the CALL interface is via a /resolve/ to the named object 
[e.g. the CALL by an explicit or library-list qualified naming, for 
which a cached address is not a documented effect], then the CALL 
will invoke the new object once the /replace/ feature has finished 
its work.  AFaIK the CALL by name [e.g. CALLX, AKA Call External] 
has the window of opportunity to experience a MCH3401 for the named 
object which does not yet exist due to the RNMOBJ or MOVOBJ having 
taken place already, yet the CRTxxx or MOVOBJ of the new object by 
the same name remains to be completed.

  You will need to know whether your program can be dynamically 
replaced according to its compatibility with the old program, how 
the program is invoked, and whether there are any poor assumptions 
about the name & location [library] of the program.

Regards, Chuck

On 01-Jul-2010 11:14, Vern Hamberg wrote:
> AFAIK there is no end-user way to redirect programs the way it's
> done with QRPLOBJ. My understanding is that jobs that are using
> a program have resolved the address of it. Either the system
> changes the resolved address in the running job to point to a
> renamed program, or it keeps the program's address and assigns it
> a new name while putting the new program at a different address.
> Something like that. I've not taken the time to use SST to see
> what happens.
>
> The only thing useful to do with QRPLOBJ for us civilians is to
> delete all instances of a changed program, IMO. I have had to do
> that occasionally to clean up things when debugging, especially
> with embedded SQL programs, it seems. Easier than signoff/singon
> sometimes.
>
> I know this doesn't help!!
>
> On 7/1/2010 12:48 PM, Rich Loeber wrote:
> > I have a situation where I have a program that was compiled on
> > a different system that I want to move into place. The program
> > may be in use when I want to install the new version.
> >
> > Obviously, just deleting the program and moving the new one in
> > would not be a great idea. Would it work to move the old
> > version of the program into the QRPLOBJ library and then
> > install the new version?
> >
> > Does anyone have any experience with doing this kind of
> > program update? I know the compiler will do this for me, but
> > the program is already compiled when I'm moving it into
> > production.