Re: More, Re: Trigger buffer problem causes lock-up

Is XREC the same as XRAW? Why 1086 & 1087 vs both 1086? AFOFF is presumably P_AFOFF+1?

If there is a pointer that exists in the data beyond the addressable buffer, and the DATA is not 16-byte aligned, then the DATA can not be dumped. I do not recall that error message, but it is something about an unaligned pointer. There is also the chance that the addressable length is exceeded, and MCH0601 results. Regardless of those two errors, the code effecting the /dump/ changes various /addressing errors/ into the text /not addressable/. Because DATA addresses something to which it has no known & valid access [e.g. for length & pointer data], there may be no ability to see in the dump, all of the variable as declared.

That addressing condition seems just a red herring, and probably the real issue is that the SUBST needs to only ever address the amount of data provided in the buffer by the database. The BUFFLEN should be part of a calculation for how much data to copy, rather than using a literal.

Regards, Chuck

James H. H. Lampert 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?