Conversion of Char to (Negative) Numeric

35 pts.
Tags:
AS/400 Printer File
AS400 Data Definitions
RPG Program
Hello, I got a problem while trying to write a record in a Printer File. My RPG program is reading a database file which has a value - DSP_FLD = "9.00J" and writing this value to a Printer file where field is as follows: PRT_FLD 5s 3 1 10EDTCDE(P) a RPG program is moving the char field to this numeric field: MOVEL DSP_FLD PRT_FLD I was expecting PRT_FLD to hold negative numeric value as -09.001 but it is showing 09.001 only; minus sign is not coming with it even after using EDTCDE(P). Can anyone help me out correcting this code so that I can convert "9.00J" to 09.000-?? Thanks a lot for your help.

Answer Wiki

Thanks. We'll let you know when a new response is added.

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.

RPG CODE
—————-
Ftestdf cf e workstn
/free
exfmt select;
highdollar = lowdollar;

exfmt select;
*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 OVERLAY
A PUTOVR
A OVRDTA
A OVRATR
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 COLOR(BLU)
A LOWDOLLAR 9Y 2B 6 18EDTCDE(1)
A 8 1′High $ . . . . :’
A COLOR(BLU)
A HIGHDOLLAR 9Y 2B 8 18EDTCDE(P)

-Sarge

Discuss This Question: 9  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    DSP_FLD = "9.00J" Your question title indicates that DSP_FLD is a character variable. If that's true, then your program should never work. You should get a decimal-data error after MOVEing the value that you show above into a numeric field. The value that you show isn't a valid numeric value. Code sample to demonstrate the error -- printer file GENPRT:
         A          R GENLIN
         A            NEGNUM         5S 3   1  1EDTCDE(P)
    RPG to move a character variable containing "9.00J" into NEGNUM for printing:
         H
         Fgenprt    O    E             PRINTER usropn
    
         d dsp_fld         s              5    inz( '9.00J' )
    
         C                   open      GENPRT
         c                   move      dsp_fld       NEGNUM
         C                   WRITE     GENLIN
         C                   SETON                                        LR
         C                   return
    It'll blow on the MOVE statement. So, something is missing out of your question. We need to see what you are really doing. We need to see the definition of DSP_FLD if nothing else. Tom
    125,585 pointsBadges:
    report
  • philpl1jb
    Well, I'm confused 9.00J The J could be -1 in signed but what is the decimal point doing there.???? I get an error moving that to a 5S 0 field .. left justified. If you had 0900J that would work fine or 900J into a 4S 0 but not with the decimal point. Of course we could remove the decimal point as part of the processing. Phil
    49,830 pointsBadges:
    report
  • TomLiotta
    If that's a character field, left justified or not, it blows. The decimal point is indeed the problem. But maybe there's a misunderstanding. If we see the definition, we might clear it up. Tom
    125,585 pointsBadges:
    report
  • Rini
    Hello, Sorry, I put wrong data (decimal) in character field earlier while writing my problem to this forum which lead you to confusion. Please find the field definition and code below to understand the issue better: Data base file fields: Field Text Len Dec ZNBFOR Field contents before maintenance 70 ZNAFTR Field contents after maintenance 70 Printer File Fields: A 43 BF053 5S 3O 045EDTCDE(P) A 43 AF053 5S 3O 045EDTCDE(P) Pgm HF1010: MOVEL ZNBFOR BF053 5 3 MOVEL ZNAFTR AF053 5 3 Data: ZNBFOR = ....5...10...15...20...25...30...35...40...45...50...55...60 1 '0200} ' 61 ' ' ZNAFTR = ....5...10...15...20...25...30...35...40...45...50...55...60 1 '0100} ' 61 ' ' Results I am getting: BF053 = 02.000 AF053 = 01.000 These fields are holding positive results, instead of holding negative data. When I tried the test code suggested by Tom, it worked but the same thing is failing in my program HF1010. I am not sure why, please advise.
    35 pointsBadges:
    report
  • graybeard52
    Try adding the command MLLZO BF053 ZNBFOR after the MOVEL. But why are you getting an "over-punch" in the input field ? Why are you using MOVEL instead of %dec( )
    3,115 pointsBadges:
    report
  • philpl1jb
    ZNBFOR = ….5…10…15…20…25…30…35…40…45…50…55…60 1 ‘0200} ‘ there is something wrong with the input field mapping. The space at the end of the value is the problem. Phil
    49,830 pointsBadges:
    report
  • TomLiotta
    From the RPG/400 manual under Move Operations:
    • For the MOVEL operation, the zone portion of the rightmost character of factor 2 is converted and used as the sign of the result field (unless factor 2 is shorter than the result field)...
    You show ZNBFOR as 70 bytes long and BF053 as only having 5 digits. BF053 is definitely shorter than ZNBFOR. The sign is not transferred. Graybeard52's suggestion to use MLLZO should help. (RPG/400 doesn't have a %dec() function.) The next question would be why would you be using an obsolete language (RPG/400) instead of a more modern and far more capable language (RPG IV) for such a tricky operation? Change your language to use RPG IV and save yourself a lot of trouble. Tom
    125,585 pointsBadges:
    report
  • TomLiotta
    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. Tom
    125,585 pointsBadges:
    report
  • Rini
    Hi Tom, I moved my data to 5 byte character field before moving it to an integer field and it worked fine. Thanks a lot for suggesting the solution and also letting me know why the error was coming. Regarding older version of RPG, there is a big list of programs that need to be converted to latest version in our project and soon it will be done. Thanks all of you for your suggestions and help. Cheers, Rini
    35 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following