× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.