On 22-Apr-2015 08:34 -0500, (WalzCraft) Jerry Forss wrote:
<<SNIP>> got a decimal data error.
I ran it in debug and found the following.
The field is Packed 5,0. Looks bad to me. The number is -1249.
402
01D
Presuming that is a hex over\under presentation, the hex string of
three bytes is x'40012D' which is a valid packed Binary Coded Decimal
(BCD) representation [for a 05P00 fixed-RPG data typing] of the decimal
value of: -40012
Clearly not -1249, but still, a valid internal representation.
Conspicuously, that the value -1249 is expected, if the three-bytes
being referenced actually started one-byte beyond what was given, then
the value in internal-form would be x'012D##' [the ## representing the
unknown data\byte that was not given above]. In that case, the hex
digit D is not valid, as the alphabetic hex digits [A-F] are only
allowed in the sign-nibble.
When I look at the record in WRKQRY it displays correctly. When I
use WRKDBF it displays correctly.
Clearly the problem is /it/, but /it/ is not well enough defined.
Seems the offset to the data that was presented above, might be
incorrect, but that does not seem to correlate well with the above
claims of the data being "correctly" displayed.
When using WRKQRY rather than SQL SELECT by Relative Row Number
(RRN), great care must be taken to ensure the row being viewed with
Display Physical File Member (DSPPFM) is the same as being viewed; i.e.
The Query/400 feature does not directly provide any ability to select-by
nor include in presentation, the RRN; only indirectly by reference to a
VIEW that includes the RRN.
When I change it via WRKDBF it puts it in like that.
To see the actual changes in another form, Start Journal Physical
File (STRJRNPF) and review the journal entry; if *BOTH images are
include, perhaps using Compare Journal Images (CMPJRNIMG) for a report
that might be perceived as making the review simpler.
There is another record in the same file that has a -1249. Looks
correct.
029
14D
And that as hex over\under would be x'01249D', which indeed, [for
05P00 RPG-fixed data typing] is the decimal value: -1249
What the he.........ck?
The system understands what it is. My pgm that takes the raw line,
parses it and makes it a number does not like it.
From the followup reply about DSPPFM finding three records and the
Query only finding two, the idea that the data being reviewed betwixt is
not the same.
When searching within DSPPFM searching for the packed BCD value is
challenging; assuming the data is known to have been converted into the
preferred-positive [0xF] and preferred-negative [0xD] then searching for
what might be the 3-byte packed BCD value for the decimal value -1249 is
done by typing the following in the Find: x'01249D'
When found, of course that value must be located within the exact
confines [start position and for length of; latter implied by string
-length] describing wherein the buffer the data for that particular
column lies.
midrange.com
