× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I am still wondering about this command.

and this SUBST statement:
C 1087 SUBST DATA:AFOFF XREC


If you use the actual length instead of a just large number will you have
the problem?

You say the problem occurs with SQL. Could be SQL is allocating memory
different. Maybe only allocating exactly what it needs vs RLA allocating a
bigger buffer. If SQL allocated exactly x bytes and you try to refer beyond
the allocation you are going to have a problem.

Better to use based variables but in lieu of that moving only what you need.


I am also puzzled by this being a general program. Don't you still end up
with a switch somewhere that says

If File A
Move to that format
If File B
Move to the format
etc.

Couldn't you just move to the actual format instead of generic record?

On Tue, Oct 27, 2009 at 12:10 PM, James H. H. Lampert <
jamesl@xxxxxxxxxxxxxxxxx> wrote:

Here's another piece of the puzzle:

The one operation that causes the trigger to blow up (and it's always
AFTER, and in this case it's tripped by an update) is an SQL call, an
UPDATE statement that changes a field in the record. All other updates
to the file use native RLA, and have no trigger problems.

So an SQL update consistently blows the trigger sky-high, while an RLA
update consistently works just fine with the trigger.

Clearly, that little detail should be telling me something. Hopefully,
it's telling me something other than "find an RLA way to do that one
operation."

As to the lengths, this is a "general case" trigger program, that is
designed to handle files whose layout (beyond a few standard fields at
the beginning) and record length (other than being >= the length of the
standard fields) are unknown at compile time, and even the length and
layout of the standard fields will vary according to which file (out of
up to 65 different ones) tripped it.

We've never seen anything quite like this before, and it's happened
twice (thankfully, to us, not to a paying customer).

We have the "first trigger parameter" defined thusly:
DPARM_01 DS
DFILENAME 1 10
DLIBNAME 11 20
DMBRNAME 21 30
DTRG_EVT 31 32
DP_B4OFF 49 52B 0
DB4LEN 53 56B 0
DP_AFOFF 65 68B 0
DAFLEN 69 72B 0
DDATA 1 10240

and we have a variable defined thusly:
D XRAW 1 1086

and this SUBST statement:
C 1087 SUBST DATA:AFOFF XREC

seems to be blowing up (maybe consistently, maybe intermittently), with
this appearing in the dump (the names have been changed to protect the
innocent)

PARM_01 DS
AFLEN BIN(9,0) 000000174.
B4LEN BIN(9,0) 000000174.
DATA CHAR(10240) NOT ADDRESSABLE
FILENAME CHAR(10) 'BAR '
LIBNAME CHAR(10) 'FOO '
MBRNAME CHAR(10) 'BAR '
P_AFOFF BIN(9,0) 000000294.
P_B4OFF BIN(9,0) 000000096.
TRG_EVT CHAR(2) '31'
PARM_02 DS
BUFFLEN BIN(9,0) 000000492.


Can anybody tell me what in blazes this "NOT ADDRESSABLE" is all about?
And why this code would suddenly start blowing up, after working as
intended for years?

--
JHHL

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

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.