Re: RJNE0100 format

[Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>]

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.