Re: Using QRPLOBJ Library

On 02-Jul-2010 09:41, Charles Wilt wrote:

Correct, renaming or moving an object doesn't change it's
address.

Renaming an object changes the object name associated with that permanent address.

In fact, address are permanently assigned to an object when it's
created and are not re-used. Think about the "% perm addresses"
on the WRKSYSACT screen

(well the "not reused" is not completely true anymore; but it
used to be and for most purposes you can still consider it to be
true.)

A permanent address for an object which has since been deleted is not reused. All future reference to the pointer will effect MCH3402 to denote the condition of "object destroyed". Note that the object to which it points no longer exists, so the message can not be so kind as to inform what the last-known object name was... since the name is not part of the pointer, but instead part of the object addressed by the pointer.

I am not sure to what "'not reused' is not completely true anymore" alludes.?

On Fri, Jul 2, 2010 at 12:06 PM, Vern Hamberg wrote:

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.

Correct. Permanent object, permanent address. Moving the object does change a pointer\address however, but that would be the pointer stored in the object to its "owning context"; i.e. into which library [index] it was inserted by {If I Recall Correctly] the MODADR instruction. As noted above, the rename changes the name of the object stored at the address location assigned to the pointer, and near that name is the pointer to the library; the LIC MI object dump via STRSST D/A/D will show where the name and its library pointer are located in the "header" of the object.

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?

Yes. The "Q" library is simply the implementation object for the OS to perform its manner of REPLACE()\RPLOBJ processing. Any permanent non-system library would suffice for implementation by anyone else.

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

I suppose, but if any opportunity exists, code dependent on the existence [per resolve-to by name] of the object which might be replaced, should probably be tolerant of the condition; coded either to handle the condition with some action [wait, retry, loop] or possibly just to effect an inquiry [e.g. by the language default handler] with means to retry.? That, or document the outcome and its recovery for the help-desk. The difference between 240ms and 470ms is moot for example, if the request to locate the object happens during any of those milliseconds in which the name is not available. Considering how many times I had to explain to a customer that CHKOBJ does not ensure an object remains even over just the several milliseconds before the next CL request failed with a "not found" against the same object name due to a RNMOBJ, DLTxxx, or MOVxxx in another process, I know that any window will eventually be hit.

<<SNIP>>

Regards, Chuck