× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.