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



You know I wonder if the issue is the length of what you are defining.
Rather than using a record that is the actual size and basing it you are
defining a data structure that is 10, 240 bytes long. Maybe when it is
trying to dump the memory it is pointing to is outside the valid memory? It
would randomly occur if this were true.

It might even be causing the actual error. You are moving 1087 bytes rather
than the actual length of the record. If that 1087 bytes happens to point
outside the valid memory it would fault. Most of the time it would work but
occasionally it would fail because it is outside the valid memory for the
program.

Just throwing darts here.

On Tue, Oct 27, 2009 at 11:28 AM, Alan Campin <alan0307d@xxxxxxxxx> wrote:

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.


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

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.