Hello, Peter:
What specific error messages are you seeing, and under what
circumstances (when)?
Restoring an object (e.g. via RSTOBJ from tape or save file) does not
safely replace program objects (*PGMs or *SRVPGMs) but instead it just
deletes the *PGM or *SRVPGM "under the covers" thus destroying the
current version of the read trigger program, while it might still be "in
use." This will cause MCHxxxx errors in any jobs where that program or
service program is active or activated.
The OS (IBM i or OS/400) does not "protect" *PGM objects (or *SRVPGMs),
e.g. by placing a *SHRRD (*USE) lock on them when they are "in use"
(e.g. called or activated in some jobs).
The compiler commands, such as CRTRPGPGM, CRTBNDRPG, CRTCBLPGM,
CRTBNDCBL, etc., provide a REPLACE parameter to help work around this
problem, and specifying *YES for this parameter allows replacing a *PGM
(or *SRVPGM) that is "in use" -- instead of just deleting the current
program, the current program is renamed to "Q"+hex-timestamp, and moved
to the QRPLOBJ library, then the new version of the program is inserted
into the target context (library).
IBM added a new API at V2R3 of OS/400, named QLIRNMO (Rename Object),
that allows you to rename and move an object with the same kind of
REPLACE(*YES) functionality that the IBM compilers provide,
Instead of just doing a RSTOBJ directly into the "target" library, you
can do this:
1.
restore the *PGM (or *SRVPGM) to be replaced into QTEMP from the
tape or save file, using the RSTLIB(QTEMP) parameter on the RSTOBJ
command
2. use the QLIRNMO API to "rename and move" the *PGM or *SRVPGM from
QTEMP to the "target" library, with the "replace" parameter value
set to "1" (= *YES)
Here is some sample code in CL:
DCL &FROM *CHAR 20 VALUE('MYPGM QTEMP ')
DCL &TYPE *CHAR 10 VALUE('*PGM')
DCL &TO *CHAR 20 VALUE('MYPGM MYLIB ')
DCL &RPL *CHAR1 VALUE('1')
DCL &ERRCOD *CHAR 4 VALUE(X'00000000')
RSTOBJ OBJ(MYPGM) SAVLIB(MYLIB) OBJTYPE(*PGM) DEV(*SAVF)
SAVF(MYLIB/MYSAVF) RSTLIB(QTEMP)
CALL PGM(QSYS/QLIRNMO) PARM(&FROM &TYPE &TO &RPL &ERRCOD)
Hope that helps,
Mark S. Waterbury
> On 10/22/2012 10:23 PM, Peter Connell wrote:
We have the strangest problem where an RPGLE program promoted to production throws an error occurs because an SQL cursor fails to open when declared over a logical file whose physical has an RPGLE coded *READ trigger attached.
Weirdly, this occurs even when the *READ trigger is *DISABLED.
Remove the *READ trigger and the problem no longer appears.
Add any trigger other than a *READ trigger and the problem does not appear.
It happens only when the file has a *READ trigger, even if it is *DISABLED. The code for the trigger is irrelevant as it can be a "null" program that simply does nothing other than exit.
Strangely, if instead of promoting the program from the development machine via the usual save/restore route, the program is recompiled from source on the production machine, then the problem does not appear.
This is unfathomable.
Peter
midrange.com
