Getting around QRPLOBJ
Njal Fisketjon (Njål Fisketjøn)
On Thu, 20 Nov 1997 21:28:08 GMT, bvs...@usa.net (Bradley V. Stone)
wrote:
>Anyone ever have any luck with problems that library QRPLOBJ can
>cause?
>Our menu system is a program, not and IBM menu. So, when we replace a
>program and someone is on the menu, and used the earlier version, if
>they go into the same option (the new version) they get that "Cannot
>resolve object" error, or use the old object. Deleteing the object
>out of QRPLOBJ doesn't do any good either. They have to sign off the
>menu and sign back on.
>
>It also seems that if they go into a program or two large enuff, it
>will "flush" some of the entries out of QRPLOBJ and if they go into
>the new program, there are no problems and the new copy is used.
>
>IBM had no answers on this... just that that's the way they decided to
>do it.
>
We have used a menu system the last 12 years (developed on S/38) and
have never experienced any big problems with QRPLOBJ.
We use a library called NEWLIB that acts as a temporary (30 days)
container for new program objects (and device files). When we use our
MOVFRMTST command objects are moved from prod.lib (extracted from
module info) to QRPLOBJ, and from TSTLIB to NEWLIB.
The reason we use NEWLIB is that it's easier to put new
display/printer files in production (if they're not already in newlib
and allocated)
Our menu system uses RCLRSC / RCLACTGRP so we do pay a performance
penalty for our scheme, but all in all, it works well for us.
Bradley V. Stone
On Fri, 21 Nov 1997 10:30:25 -0600, Gary Guthrie
<ggut...@airmail.net> wrote:
>Hi Bradley,
>
>Sounds as if your menu system is an RPG program. Once the pointer to a
>program that is called is resolved, RPG doesn't re-resolve the pointer.
>This is the root of your problem. The pointer points to the object in
>QRPLOBJ now instead of the production library. This is for performance
>reasons. Resolving system pointers is a fairly expensive task.
>
>A possible work around would be the following:
>
>1) Presume your menu program is called MENURPG.
>2) Create another program MENUFIRST (any flavor will do), that simply
>calls MENURPG and loops
>3) Modify MENURPG so that after an option is taken, it exits with LR on
>
>This will cause the system to re-resolve the pointers next time in the
>RPG program. Upon exit, control is returned to MENUFIRST, which in turn
>simply calls MENURPG again.
>
>Of course, depending on your setup you might need to pass parameters
>between MENURPG and MENUFIRST to act as communication (for instance,
>loop again, signoff, whatever).
>
>Gary Guthrie
Thanks Gary. Interesting solution.
Here's one I that I wonder will work. The object names in QRPLOBJ are
random (ie Q0DCA7A34A with a description of library/pgmname).
Would it be possible that when sending new objects we not only replace
the original object, but the objects in QRPLOBJ as well? Like reading
the object description to find out which ones are the programs we want
to replace, save the random name, delete the object, and then replace
it with the new one but name it the same as before (ie Q0DCA7A34A).
I haven't tried putting objects into QRPLOBJ, so who knows if this
will work. Just an idea.
Bradley V. Stone
bvs...@usa.net
http://prairie.lakes.com/~bvstone/
1992 Yamaha FJ1200
1969 Suzuki T250
"I got this Jookie Sea Captain!" "Arrr!"
Martin Neugebauer
Bradley V. Stone wrote:
> Here's one I that I wonder will work. The object names in QRPLOBJ are
>
> random (ie Q0DCA7A34A with a description of library/pgmname).
>
> Would it be possible that when sending new objects we not only replace
>
> the original object, but the objects in QRPLOBJ as well? Like reading
>
> the object description to find out which ones are the programs we want
>
> to replace, save the random name, delete the object, and then replace
> it with the new one but name it the same as before (ie Q0DCA7A34A).
>
> I haven't tried putting objects into QRPLOBJ, so who knows if this
> will work. Just an idea.
Brad, you are a hell of a cowboy (hacker)!
This is NOT a good idea in the first place, and it does not solve the
problem.
Your program has a pointer, ie. a reference to a machine adress. No
matter what you do to the object that's pointed to, the pointer just
continues to point there. Putting another object in there, won't get the
same machine adress. Period.
The solution is to invalidate the pointer. Either, as Guthrie suggested,
leave the program (i don't think you would even have to set *INLR), OR
call the other programs via a variable name (eg. CALL varname, where
varname contains 'MYPGM'). In that case, you can invalidate the pointer
by changing varname's contents, eg. to 'XXX' and back to 'MYPGM'. This,
of course, causes the waste of some milliseconds, because the OS has to
re-establish (link) the reference to mypgm every time that menu option
is chosen, but for interactive use (keyboard interaction) this is
neglectible.
See ya, Martin.
Bradley V. Stone
>Bradley V. Stone wrote:
>
>> Here's one I that I wonder will work. The object names in QRPLOBJ are
>>
>> random (ie Q0DCA7A34A with a description of library/pgmname).
>>
>> Would it be possible that when sending new objects we not only replace
>>
>> the original object, but the objects in QRPLOBJ as well? Like reading
>>
>> the object description to find out which ones are the programs we want
>>
>> to replace, save the random name, delete the object, and then replace
>> it with the new one but name it the same as before (ie Q0DCA7A34A).
>>
>> I haven't tried putting objects into QRPLOBJ, so who knows if this
>> will work. Just an idea.
>
>Brad, you are a hell of a cowboy (hacker)!
>
Giddyup!
Gary Guthrie
OSITim
We have no problems with QRPLOBJ. The best way to avoid problems is with some
procedural changes on your part.
1. Create a library for where you place new program objects, display files,
printer files etc... Put this library ahead of the library where you keep your
production programs. For example:
NEWPGMS
PRODUCTION
PGMLIB
QGPL
etc.
2. Never create program objects directly into libraries that are in your
production library list. Rather move them there after they are created.
3. Your menu program should use a variable name for the name of called program
in your CL or RPG menu program. This will cause OS/400 to re-resolve the
program object and therefore pickup any additions to the NEWPGMS library.
Gary Guthrie
> 3. Your menu program should use a variable name for the name of called program
> in your CL or RPG menu program. This will cause OS/400 to re-resolve the
> program object and therefore pickup any additions to the NEWPGMS library.
I'm not sure that's the case anymore.
Douglas Handy
Brad,
>>> I haven't tried putting objects into QRPLOBJ, so who knows if this
>>> will work. Just an idea.
>>
>>Brad, you are a hell of a cowboy (hacker)!
I haven't tried this either, but I don't have to try it to tell you it
won't work. The system could care less what the name of the program
is or what library it is in. It never looks in QRPLOBJ per se or
again reference the new name of the object. The original object still
exists and has the same address and that is all that matters. The job
still has a pointer to this address, and uses it instead of resolving
the library/name again. As soon as you delete the object in QRPLOBJ,
the pointer will be invalidated and the original job will have a
problem. If you rename the QRPLOBJ copy and put a different version
in it by the same name, it still won't ever resolve to the new program
but will continue to use the original program regardless of what you
name it to or what library you move it to. The library QRPLOBJ and
uniquely generated names are just used because objects have to be
called something...
In a nutshell, there is *no way* to do what you are trying to
accomplish. Or at least I would be *very* surprised if there was.
Even if you could hack your way through the program stack and find the
pointer in memory to the old program, if you change it the *hardware*
will detect it and will automatically invalidate the address...
Doug
Martin Neugebauer
Bradley Stone wrote:
> >>Brad, you are a hell of a cowboy (hacker)!
> > Giddyup!
Brad, could you explain the meaning of your message? I'm not a native
speaker and don't get it.
I did not mean to insult you with the above wording, just admired your
boldness.
Regards, Martin.