Re: Updating a triggered record, part deux

   Scott, this does help.  Thank you for your answer to this one (and you
   were right about the origin of the code: it's been around). 

   Your recent articles have also been excellent in terms of both context and
   context.  I don't print much but I'm printing them!

   -rg

   >From: Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
   >Reply-To: RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
   >To: RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
   >Subject: Re: Updating a triggered record, part deux
   >Date: Thu, 17 Jun 2004 00:02:03 -0500 (CDT)
   >
   >
   > >    But I'm embarrassed to be suffering from frain bade: I'm using
   pointers to
   > >    get the before and after record images into data structures so I
   can
   > >    handle the normal application stuff but can't, for the life of me,
   figure
   > >    out how to stick AIMAGE, with its trigger program updates made
   through the
   > >    data structure, back into the buffer.
   >
   >AIMAGE occupies the same area of memory as the buffer.  When you change
   >AIMAGE, you're changing the buffer.
   >
   >When you say intptr = %addr(qdbtb) what you're doing is telling the
   >computer that you want intptr to contain the address -- that's the
   >position in the computer's memory -- where the qdbtb field is stored.
   >Since intarr is BASED on intptr, that means the intarr will occupy the
   >same area of memory as qdbtb does.  When you set aimage =
   >%addr(intarr(qdboro+1)) you're telling it that you want q_after_ds to
   >occupy the same memory as that particular element of the array.  If
   qdboro
   >has a value of 104, then you're putting q_after_ds into the same memory
   as
   >the 105th element of intarr.
   >
   >Since intarr(1) is in the same place in memory as qdbtb, that means that
   >intarr(105) is 104 bytes later in memory than the start of qdbtb.  In
   >other words, it's "104 bytes offset from qdbtb" -- thus the name "offset"
   >
   >Actually, the array method is the hard way to do this.  The reason you're
   >using an array is likely that you copied code from someone who had
   written
   >their code for V3R1, V3R2 or V3R6.  (Which makes sense, since it was
   about
   >that time that people were writing articles and manuals about triggers)
   >
   >Since V3R7, RPG has been able to do pointer arithmetic.  That means to
   get
   >an address that's 104 bytes later than another address, all you have to
   do
   >is eval ptr = %addr(whatever) + 104.
   >
   >So, you could easily eliminate intarr/intptr completely, and just do:
   >
   >     eval bimage = %addr(qdbtb) + qdboro
   >     eval aimage = %addr(qdbtb) + qdbnro
   >
   >The point of all this, though, is that BIMAGE is in the same area of
   >memory as the "before image" part of the parameter you were passed, and
   >AIMAGE is in the same memory as the "after image' of the parameter you
   >were passed.
   >
   >That means that when you change AIMAGE, you *ARE* changing the
   buffer.  No
   >further steps are required -- just change a field in AIMAGE and you're
   >done.
   >
   >Hope that helps you understand...
   >--
   >This is the RPG programming on the AS400 / iSeries (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.
   >

     ----------------------------------------------------------------------

   Is your PC infected? Get a FREE online computer virus scan from McAfee(R)
   Security.