Re: QRPLOBJ Library

MOVOBJ changes object library reference, but does not change object
address.
RNMOBJ changes object libtrary reference, but does not change object
address.
When object is being placed in QRPLOBJ, it is moved and renamed, but
physically it is still the same object, so whoever had a pointer reference
to an object, will enjoy using the same object, whatever it's new name and
library.

Program stack does not have program names or libraries - only pointers.
When you display stack for a job, pointer will be materialized and you will
see whatever program object name and library was at the moment of
materialization.

When program is being run, it is not locked, so you can delete it, which
can have adverse effect on running programs (most probably addressing
exception) - hence the need for QRPLOBJ library.

Unlike programs, files are locked when used. So if you are able to delete a
file, you are guaranteed that nobody uses it. So normally there is no need
for QRPLOBJ approach for file. This also applies to other object types.

Hope it will make it clearer for you...

    Alexei Pytel


"Allen Overeem" <AOvereem@stvgb.org> on 01/28/2000 09:53:10 AM

Please respond to MIDRANGE-L@midrange.com

To:   MIDRANGE-L@midrange.com
cc:
Subject:  QRPLOBJ Library




Help! I put a question to the list some time back about this, but did not
get the response I was hoping for.  Perhaps I need to modify my question
extensively.
On our AS400e v4r4 we have a library called production. Pgmrs have test
libraries.
We have a move process written in cl and cobol. Whenever a program is moved
from test into production, this move process is used. When the move is
done, the program to be moved is NOT running. During the move, any version
of this object in qrplobj is deleted, the existing production program
object is forced to QRPLOBJ library with the movobj command. The test
program object is then moved to production.
We also have a special little recompile process written in cl. When an
object is recompiled: any version in qrplobj is deleted, the existing
object is first forced to QRPLOBJ with the movobj command, the existing
source is compiled into new pgm object in production.
I had an incident recently where I made some changes to a program that took
a right justified field. left justified it and output it. The program
object was moved into production.  At that point, there are ( unless IBM
stores them somewhere else on a movobj??) only two program objects on the
system: the one we forced into QRPLOBJ and the one we forced from my test
library into production. After starting program again, it becomes obvious
that the changes are not in affect; without a doubt. Doing a wrkobj at this
time shows that only two versions of object exist, as I mentioned.  Looking
in call stack for active program object shows that the object running is
the one in production.
Doing a recompile (no changes to the source code) fixes the problem.

My Questions:

1. Is there ever a time when the call stack will show that version of
object in one library is running when in fact it is the version in QRPLOBJ
that is running?

2. Could the force of the object to QRPLOBJ system library cause the kind
of behavior I am describing?

TIA

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---



+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---