RE: Journal API Troubleshooting

[Scott Klement <klemscot@xxxxxxxxxxxx>]

[SNIP]
>      D JournalSelect   DS                  Qualified
>      D  RecCount                      4B 0 Inz(100)
>      D  VarLenRecLen                  4B 0 Inz(285)
>      D  Key                           4B 0 Inz(16)
>      D  KeyLen                        4B 0 Inz(34)
>      D  FileElemCount                 4B 0 Inz(1)
>      D  Filename                     10A   Inz('TRANS')
>      D  Library                      10A   Inz('E06FILES')
>      D  Member                       10A   Inz('TRANS')

When the API documentation says Bin(4) or Binary(4) you need to use "10I0"
in RPG.

Never use the B data type!  Never! Never!  It's an awful remnant of RPG3
that's never worked the way people expected it to.

And, in any case, Bin(4) does not mean "4 digit binary".  It means "4
*byte* binary."   Yet, in RPG we define our data by the number of digits,
rather than the byte size.

If you have a packed number like "9P 0" that number is 9 digits long, but
only takes up 5 bytes.  Likewise, if you have a "10I 0" it stores 10
digits, but takes up 4 bytes.


> When I add the JournalSelect to the Call(P) statement, I get the following
> error:
>
> CPF3C82 - Key 123865 not valid for API QjoRetrieveJournalEntries
>
> Now, the value 16 is supposed to be sent as the key.  So I tried viewing the
> data structure in hex, and attempted to decode the value 123865 into binary,
> then hex, to determine where it is grabbing the key value from, to adjust my
> data structure, but I am not sure how the binary coding works for
> negative-capable fields.

Why do you get 123865?  Because your data structure is wrong.   Keep in
mind  that the API cannot see what's happening in your program.  All it
gets is a pointer to some spot in memory, and it has to interpret that memory
according to it's own rules.

Unfortunately, "4B0" is only 2 bytes long.  Let's look at how your current
data structure is layed out positionally:

      D JournalSelect   DS                  Qualified
      D  RecCount                      4B 0 Inz(100)         Pos  1 - 2
      D  VarLenRecLen                  4B 0 Inz(285)         Pos  3 - 4
      D  Key                           4B 0 Inz(16)          Pos  5 - 6
      D  KeyLen                        4B 0 Inz(34)          Pos  7 - 8
      D  FileElemCount                 4B 0 Inz(1)           Pos  9 - 10
      D  Filename                     10A   Inz('TRANS')     Pos 11 - 20
      D  Library                      10A   Inz('E06FILES')  Pos 21 - 30
      D  Member                       10A   Inz('TRANS')     Pos 31 - 40

So, the API is looking for the key at position 9-12 (or "offset 8 for a
length of 4")  That means that it will get "FileElemCount" and the first
two bytes of "Filename" from your data structure because THAT'S what's in
positions 9-12.

What are those 4 bytes in hex?

FileElemCount = x'0001'
First 2 bytes of Filename = x'E3D9'

If you take x'0001E3D9' and convert it to decimal you get 123865.


>
> So I am stuck again, any help would be greatly appreciated.
>

I probably gave you far more info that you needed :)   At any rate, always
remember that "Binary(4)" is "10I 0"... and always remember that
"Binary(4) Unsigned" is "10U 0" and you'll save yourself a lot of time
debugging :)