|
Hmmm...guess I'm not sure about this after all. I'm using the RCVJRNE command and the ENTFMT(*TYPEPTR) parameter. The manual says: "For ENTFMT(*TYPEPTR), the format of this data is the same as RJNE0100 in the Retrieve Journal Entries (QjoRetrieveJournalEntries) API. " That's why I was using the RJNE0100 format description. The exit program (that I wrote) is specified in the RCVJRNE command and is passed two parameters - data in the RJNE0100 format and a 3 byte control field. How do I specify the first parameter? As a long string (varying length?) and then use the displacement and offset to determine the positions of the contents? - Michael -----Original Message----- From: michaelr_41@xxxxxxxxxxxxxx [mailto:michaelr_41@xxxxxxxxxxxxxx] Sent: Wednesday, June 30, 2004 4:34 PM To: Midrange Systems Technical Discussion Subject: Re: RJNE0100 format 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 -- michaelr_41@xxxxxxxxxxxxxx
As an Amazon Associate we earn from qualifying purchases.
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.