Re: RJNE0100 format -- MIDRANGE-L

Wow...thanks Scott. I did change the binary to Integer, but thought it
was the Align. I'll make the change you recommend.

- Michael

On Wed, 30 Jun 2004 15:08:12 -0500 (CDT), "Scott Klement"
<midrange-l@xxxxxxxxxxxxxxxx> said:
> 
> On Wed, 30 Jun 2004 michaelr_41@xxxxxxxxxxxxxx wrote:
> >
> > Found it...I didn't specify Align on the data structure and the data
> > could contain pointers. This seemed to fix it:
> >
> > D JrnEntry        DS                  Align
> >
> 
> That's not why the ALIGN keyword solved the problem, read on...
> 
> [SNIP]
> > BYTESRETURNED OF JRNENTRY = 000000240.
> > HEADEROFFSET OF JRNENTRY = 000000016.
> > JOURNALOFFSET OF JRNENTRY = 000000001.
> > CONTINUATION OF JRNENTRY = '1'
> [SNIP]
> > D JrnEntry        DS
> >  *  Header Entry
> > D  BytesReturned                 9B 0
> > D  HeaderOffset                  9B 0
> > D  JournalOffset                 9B 0
> > D  Continuation                  1
> >  *  Journal Entry Header
> > D  DspNxtJrnHdr                  9B 0
> [SNIP]
> 
> The API is *sending* you a number that tells you how far the
> "journal entry header" data structure is from the "header" data
> structure.
> It's called HeaderOffset in your code...
> 
> You are ignoring the value that it sends you in HeaderOffset, and instead
> hard-coding the position of the header. Since you have 3 fields that are
> 4
> bytes long, followed by a field that's 1 byte long, you're hardcoding
> DspNxtJrnHdr as 13 bytes after the start of the data structure.  When you
> coded the ALIGN keyword, it forced DspNxrJrnHdr to be aligned on a 4-byte
> boundary -- so it rounded the 13 up to the next multiple of 4 which is
> 16.
> By sheer luck, the API happened to pass 16 in the HeaderOffset field, so
> it worked.
> 
> What will you do if the API sends you a different value besides 16 in the
> HeaderOffset field?  Sure, you can say "it's never done that"  or you can
> say "if it ever does that, I can change my program" but is that really
> the
> right way to write code?
> 
> The "Header", "Journal Entry Header", "Journal Entry Null-Value
> indicators", and "Journal Entry Specific Data" parts ot JRNE0100 should
> be
> coded as separate data structures -- as they are in the documentation --
> and should be distanced from one another based on the values in the
> "offset"
> and "displacement" fields.
> 
> Also, the API documentation is calling for BINARY(4) and BINARY(4)
> UNSIGNED fields... you're using 9B 0 which isn't a true BINARY(4).  9B 0
> is a decimal field, not a binary field.  If the number exceeds 999999999,
> the RPG runtime will chop off the most significant digits.  And, in any
> case, it's a signed field -- the B data type is never unsigned.
> 
> I can't say this enough times -- Unless you're coding at V3R6/V3R1,
> there's no reason to EVER use the "B" data type in RPG IV.  Use the I and
> U data types instead.
> 
>   BINARY(4)          = 10I 0 in RPG IV,
>   BINARY(4) UNSIGNED = 10U 0 in RPG IV.
> 
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
> 
-- 
  
  michaelr_41@xxxxxxxxxxxxxx