Re: Using QRPLOBJ Library

Chuck

Thanks for the explanation - so I think I'm seeing that putting an object in a different library does not change its address on the system. Even renaming doesn't do that, so that explains why a job running it can still use it, if resolved by address.

Actually this would suggest that moving to ANY library or renaming the program can be done, it doesn't have to be QRPLOBJ - is this true?

Also, it seems the window of vulnerability for the MCH3401 could be minimized by using the API mentioned in another post.

Vern

On 7/1/2010 2:12 PM, CRPence wrote:

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.