|
Well I'll be ........
Closer look at the code reveals that the cursor was being declared over a
logical instead of a physical.
Changing it to use the physical fixed the problem.
Peter
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Paul Therrien
Sent: Wednesday, 24 October 2012 8:45 a.m.
To: RPG programming on the IBM i / System i
Subject: RE: RPGLE with embeded SQL cursor over file with *READ trigger
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 toproduction 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.appear.
Remove the *READ trigger and the problem no longer appears.
Add any trigger other than a *READ trigger and the problem does not
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.
machine via the usual save/restore route, the program is recompiled from
Strangely, if instead of promoting the program from the development
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.
--
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.