This really sounds like a PTF issue. Are all of your machines at the same ptf level?
Paul
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Peter Connell
Sent: Tuesday, October 23, 2012 1:45 PM
To: RPG programming on the IBM i / System i
Subject: RE: RPGLE with embeded SQL cursor over file with *READ trigger
The restore operation is not pertinent. I did not mention that when investigating the error I restored the program to a different library and signed on and off before each test.
Executing the program from either library on the production machine produces the same error.
MCH3601 sent to QSYS/QQQITEMP as an escape msg - Pointer not set for location referenced.
CPF4204 sent to QSYS/ QQQQUERY as an escape msg - Internal failure occurred in query processor.
There are 3 machines, DEV, QA and PRD. Compiling from source on each works.
Strangely restoring from QA to PRD works but restoring from DEV to PRD produces the SQL error.
Perhaps there's something about the SQL runtime environment on PRD that is different on DEV and which is connected to the program via the SQL pre-compiler.
Peter
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Mark S Waterbury
Sent: Tuesday, 23 October 2012 4:16 p.m.
To: RPG programming on the IBM i / System i
Subject: Re: RPGLE with embeded SQL cursor over file with *READ trigger
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
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
#####################################################################################
This correspondence is for the named person's use only. It may contain confidential or legally privileged information, or both. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this correspondence in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or rely on any part of this correspondence if you are not the intended recipient.
Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views of Veda.
If you need assistance, please contact Veda on either :- Australia 1300-762-207 or New Zealand +64 9 367 6200
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
midrange.com
