Re: Trigger buffer problem causes lock-up

The only thing I notice is that the Trigger Event is defined incorrectly. My
layout is below.

The weird part is the data overlays the buffer and you can see the data
fields but the data is undefined. Almost looks like something is getting put
out to the dump incorrectly. Is the error you are getting is invalid
pointer?

The only other thing I notice is that you are looking at the after buffer
only which will be invalid if you are running a delete event. Only the
before is passed but the event says update. Are we sure this is a update
event?

I agree with Charles about using based structures. I define my incoming
records this way.

d BeforeRecord...
d e ds ExtName(Table1)
d Based(ptrBeforeRecord)
d AfterRecord...
d e ds ExtName(Table1)
d Based(ptrAfterRecord)

Then it is just math.

ptrBeforeRecord = %Addr(TriggerBuffer) + InBeforeBufferOffset;
ptrAfterRecord = %Addr(TriggerBuffer) + InAfterBufferOffset

StdNam = Standard Name 10 bytes.
StdChr = Standard Character 1 byte.
StdInt = Standard Integer 4 bytes.

d DbTriggerBuffer...
d ds Qualified
d Based(ptrDbTriggerBuffer)
d PhysicalFileName...
d Like(StdNam)
d PhysicalFileLibrary...
d Like(StdNam)
d PhysicalFileMember...
d Like(StdNam)
d TriggerEvent...
d Like(StdChr)
d TriggerTime...
d Like(StdChr)
d CommitLockLevel...
d Like(StdChr)
d Reserve1...
d 3
d CCSIDOfData...
d Like(StdInt)
d RelativeRecordNumber...
d Like(StdInt)
d Reserve2...
d 4
d BeforeOffset...
d Like(StdInt)
d BeforeLength...
d Like(StdInt)
d BeforeNullByteOffset...
d Like(StdInt)
d BeforeNullByteLength...
d Like(StdInt)
d AfterOffset...
d Like(StdInt)
d AfterLength...
d Like(StdInt)
d AfterNullByteOffset...
d Like(StdInt)
d AfterNullByteLength...
d Like(StdInt)
d Reserved3...
d 16



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

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.