Sorry, I messed up an important part.
BF053 is definitely shorter than ZNBFOR, so the specific restriction doesn't apply. But it does indicate the problem. The "zone" bits are not in position 5 of ZNBFOR -- they are in position 70 because ZNBFOR is 70 bytes long. But position 70 contains a blank. A blank is going to be treated as a zero with no sign (or positive).
And that means that even MLLZO won't help.
The easiest way out is to create a 5-byte field, use MOVEL to move the value from ZNBFOR into the new field, then move that value into BF053.
That is, that's the easiest way in RPG/400.
It's been too long since I've had to use RPG/400 that I'm forgetting a lot of it. It'd be much better just to quit using it. It should have been discarded more than ten years ago.
i created this small program to test and i have no issues. when i enter 9.00 and field minus, i get 9.0} which, when it places that value in high-dollar with edit code (P), i get the -9.00 i expected.
Ftestdf cf e workstn
highdollar = lowdollar;
*InLr = *On;
DDS for DSPF
A R SELECT
A*%%TS SD 20100716 084538 BMYRICK REL-V5R4M0 5722-WDS
A WINDOW(5 2 12 74 *NOMSGLIN)
A WDWTITLE((*TEXT ‘ Donations by Date-
A Range ‘) *CENTER)
A WDWTITLE((*TEXT ‘ F3=Exit F5=Proce-
A ss ‘) *CENTER *BOTTOM)
A 6 1′Low $. . . . . :’
A LOWDOLLAR 9Y 2B 6 18EDTCDE(1)
A 8 1′High $ . . . . :’
A HIGHDOLLAR 9Y 2B 8 18EDTCDE(P)