RE: RPGLE with embeded SQL cursor over file with *READ trigger -- RPG400-L

Well spotted Dave. I had obviously stated but underestimated the significance of the logical, perhaps because I didn't actually write the code in question.
And possibly because I tried issuing the same SQL select statement using the logical via STRSQL and also via a REXX script that declares exactly the same SQL cursor using the logical and both of these worked fine.
It was just the embedded SQL that did not work with a logical. Personally, I always code to the physical not the logical.
This has prompted a development standard that we should always code to the physical to avoid the error in future.

Peter

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Dave
Sent: Thursday, 25 October 2012 10:13 p.m.
To: RPG programming on the IBM i / System i
Subject: Re: RPGLE with embeded SQL cursor over file with *READ trigger

Closer look? You indicated it was a logical in your first post! I thought about advising you to not use the logical as it would be used I think anyway when the query was run. Then I thought we have some logicals that would not get used because of select/omit parameters, etc, so maybe you intentionally used the logical in your query.

2012/10/24 Peter Connell <Peter.Connell@xxxxxxxxxx>

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 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.

--
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