It looks like we're not handling the change from positive to negative
properly on a non-signed numeric field.
To handle it properly, the 6th bit in the last byte of the numeric field
should be turned off. i.e. "0" (0xf0) becomes "}" (0xd0), "1" (0xf1)
becomes "J" (0xd1), etc.
What we were (incorrectly) doing is concatenating a "}" to the end of
the field, no matter what the value of the field was. Essentially, we
were always adding a zero to the end, and making it negative.
I've sent a patch to Sean Porterfield and Juan Rivas (who have both
mentioned this problem) and if they're happy with the results I'll
pass the patch along to Jason to be applied...
Thanks for all your help finding this stuff... :)
On Mon, 22 Jan 2001, Sean Porterfield wrote:
> Repost: Does the list block messages with attachments (or a max file
> size?) Anyway, instead of attached, trace available on request.
>
> ---------------------------------------------------------
>
> I thought all the field minus / field exit problems had been fixed, but
> maybe I just don't use field minus enough.
>
> When I key 1 then field minus, I see 10- in the field (after pressing
> enter). I know of a few places this happens, but order entry is the
> most important! (I can't give this out to users as is.)
>
> Trace file attached in case someone has an idea.
>
> Thanks!
+---
| This is the LINUX5250 Mailing List!
| To submit a new message, send your mail to [EMAIL PROTECTED]
| To subscribe to this list send email to [EMAIL PROTECTED]
| To unsubscribe from this list send email to [EMAIL PROTECTED]
| Questions should be directed to the list owner/operator: [EMAIL PROTECTED]
+---
