How Do I Prevent RPG Low-Order Truncation When Storing Data In A File??

110 pts.
Tags:
AS/400
RPG
I am calculating GPA to print on a report and store in a secondary file via RPG on an AS400.  When I print the GPA on the report, there is no low-order truncation; however, when I store this same field in my secondary file, low-order truncation occurs.  How do I prevent this??

Code as follows:

TOTQTY DIV TOTATT GPA 54

TOTQTY is defined as 41.

TOTATT is defined as 31.

GPA is defined as 54 on the report and in the secondary fle.

67.0/18.0 = 3.722[strong]2[/strong] (prints on report)

3.722[strong]0[/strong] is stored in the secondary file (HEX values of F3 F7 F2 F2 F[strong]0[/strong]).

Output specs:

QSYSPRT...

     GPA    1  54

TEMPFLE (secondary file)

    GPA     X

Thanks!

 

Answer Wiki

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

I would do a DSPFFD of TEMPFLE to be sure GPA is defined with 4 decimal places. Otherwise their is not a logical reason I can think of that would cause your problem.

Discuss This Question: 11  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
    TEMPFLE (secondary file) GPA X Can you please clarify what those two lines mean? What is the "X" for? Tom
    125,585 pointsBadges:
    report
  • Pixieprogrammer
    Charlie: GPA is defined with 4 decimals. Here is the DSPFFD of TEMFLE: SG2GPA ZONED 5 4 5 648 Both GPA Field text . . . . . . . . . . . . . . . : GPA The DDSSRC is defined as 5S 4. The CPYSRC is defined as 9(01)V9(04), though I do not use the CPYSRC field for any moves. Tom, The "X" is an edit code in the output spec. I know that most places don't use that edit code anymore, but this is an inherited program that was been brought up to RPG400 standards (not by me). When I remove the edit code and submit the job again, the data in the result field is the same: low-order truncation. I tried using other edit codes, but I get all types of garbage. We are on operating system V5R4M0 with RPG/400.
    110 pointsBadges:
    report
  • TomLiotta
    I don't have an answer. As CharlieBrowne said, it should work. There may still be some inconsistencies or things that need clarification though. I created two trivial source members -- one for a PF and one for basic RPG/400 calculation and output. The program is:
         H
         FTSTDIV  O   E                    DISK
         C                     Z-ADD67.0      TOTQTY  41
         C                     Z-ADD18.0      TOTATT  31
         C*
         C           TOTQTY    DIV  TOTATT    GPA     54
          *
         C                     Z-ADDGPA       SG2GPA
          *
         C                     WRITETSTDIVR
          *
         C                     SETON                     LR
    And the file written by that program is:
         A          R TSTDIVR                   TEXT('Test division file')
         A*
         A            COMPNY         6A
         A            SG2GPA         5S 4B      TEXT('GPA')
         A            NAME          35A
    After running the program, the value in SG2GPA is:
    ..1....+
     SG2GPA 
     3.7222 
    Exactly as expected. A particular inconsistency is that you have been asking about a field named "GPA", but you showed output from DSPFFD for a field named "SG2GPA". That field is ZONED in your file. That isn't critical, but it sort of slips past a detail of RPG/400 calculations in that calculations are performed with packed-decimal values and conversion is done where needed. Packed and zoned should have no problem, but it's the kind of detail that is probably involved here. As it is, with one variable being (4,1) and another being (3,1), the definition of GPA as (5,4) is already a ways outside of what it should be. GPA really should be at least (7,5) and probably even (9,5) to handle the range of potential truncation/rounding inaccuracies that can occur. But that's simply 'good' programming; it's probably not the core problem in this case. Anyway, the division works using the values that you supplied; and the output record has the expected value. I used default parameters for the compilations (except for *LSTDBG so I could use STRDBG.) You should be able to copy/paste both the DDS and RPG source and compile and get the same result that I got. If you get a different result, you might also be able to think about what happens to the value inside your program to see where it might be going wrong. Without seeing your source, and possibly a compile listing, there are too many possibilities. Tom
    125,585 pointsBadges:
    report
  • philpl1jb
    Ohhh, Cobol copy book!!! Old code!!! Is the f-spec Fixed or External? Is the next field on the I specs or O spec's for the file overlapping this field? Phil
    51,365 pointsBadges:
    report
  • Pixieprogrammer
    Tom, First, GPA is the name of the field in the RPG source. The other is the name from the DDS source. I know it is not "good" programming for the names to be inconsistant. It drives me up the wall frankly, but I didn't write this nor do I have the "liberty" to rewrite it. You don't know how many programs I've come across and screamed "this is crap!!". I am not supposed to share our code with anyone as our code is copyrighted. Soooo, now that I've let that out, onto solving this mystery. GPA size: RPG rules for division state that "when dividing by a value of 1 or greater, the maximum required positions to the left of the decimal in the result is the number of left-of-decimals in the dividend (the value being divided)". So I adjusted the size of GPA because of the division rules, but it too has not helped. I get a dde (data decimal error) or inaccurate data every time I change the size to something other than 54. If I go 44, then there is no GPA data on the report and the file has .7222 - HEX F7 F2 F2 F0. If I go 75 or 95, the data on my report is .72222 and the file gets 7.2220 - HEX F7 F2 F2 F2 F0. I also tried increasing the decimal positions. It appears to still be low-order truncation. I went 55 and the report is .72222 and the file gets 7.2220 - HEX F7 F2 F2 F2 F0. What you have in your test RPG and PF is basically what I have in mine with the exception that I don't have the values hardcoded in my RPG, and I leave my GPA type blank in the PF instead of "B". Use of the GPA field: just before I write this value to the secondary file in the O specs, I print this value on a report. That's all that happens. The report shows the value 3.7222, but like I orignally stated, the value written to the secondary file is 3.7220. Phil, Yes, COBOL copy book, but I do not use it in this particular job. Yes, old code. F spec is fixed. No, I am not overlapping data. The O spec has my GPA ending in pos 652. The next field should begin in 653, and when I DBU the file, that is exactly where the next field begins. That field is actually the dividend in the GPA equation. In this example value 67.0 - HEX F6 F7 F0 in a field that is defined in the PF as 4S 1.
    110 pointsBadges:
    report
  • philpl1jb
    Right, thanks for the trip in the way-back machine .. the COBOL and all. The value 67.0 - HEX F6 F7 F0 in a field that is defined in the PF as 4S 1 Wrong the value is not 67.0 - HEX F6 F7 F0. at least not if it's 4S1 and that's probably why you are losing the last digit of the previous field. The value that you're putting into your file is 067.0 - HEX F0 F6 F7 F0 it's that leading zero that you didn't have room for in the file and writes over the last digit of the data in the previous field. Of course, I've never maddd a mistake. Phil
    51,365 pointsBadges:
    report
  • TomLiotta
    GPA is the name of the field in the RPG source. Right. That's because it only exists in the RPG program. You show how it is (apparently) defined with this statement:
       TOTQTY DIV  TOTATT    GPA    54
    However, you are telling us about an error in a different field, the field in the file -- SG2GPA. But we don't see what happens to GPA before the value is copied to SG2GPA. And we don't see how the copy is done -- with Z-ADD, perhaps? (...program-described O-specs??) I don't mind too much that a variable is created for calculation and it has a name different from the field in the file. If you're coding OPM RPG, you don't have any choice -- the name must be different or it will be the same field. Personally, I prefer naming work fields uniquely. I apologize for poor wording for this part. The thought about "good" programming was about the choice of scale and precision rather than the name. The word "good" was the only one I could think of to bring in ideas about how stuff should be done in order to cover all fringe possibilities. I rarely do most of the "good" practices myself. But when a problem appears, it's the first area that needs to be reviewed. Tom
    125,585 pointsBadges:
    report
  • philpl1jb
    Tom I think you missed a message. This programs F spec is Fixed and the output is defined in O specs..so it doesn't matter what the fields are called in the file. The O spec after GPA has it's ending position wrong so it's overwriting the last digit of the GPA field. I'm really, really old but I wasn't on the 400 when this type of code was written. Phil
    51,365 pointsBadges:
    report
  • TomLiotta
    This programs F spec is Fixed and the output is defined in O specs.. Yep. I see how it's mentioned now. Of course, manually coding O-specs when an external description is available is one of the most likely causes of this problem. We need to see the O-specs if that's the case. Tom
    125,585 pointsBadges:
    report
  • Pixieprogrammer
    I did get this corrected. Sorry I haven't had time to put up the solution. Phil's question about overwriting data led me to the problem. The next field (TOTQTY) in the file was not properly defined in the DDSSRC. It was 3S 1 instead of 4S1 (after a week staring at this who could blame me for the mistake), so there was an extra leading zero in TOTQTY that overlapped the last byte of GPA. Also, looking more into some of the suggestions on size, I changed it in the RPGSRC to be 3S 1 as that was all I truly needed size wise. Recompile, resubmitted and ta-da - the fields were correct, and I heard a chorus of angels singing!! Thank you all for the help!! It got me looking at (and remembering) a lot more stuff which is a good thing considering I am now the only person in our shop with "RPG experience". Yikes!! Have a blessed day!!
    110 pointsBadges:
    report
  • philpl1jb
    Cool. but I'm concerned that TOTQTY should be 4.1 not 3.1 If TOTATT is 25 and all grades were 'A' -- then TOTQTY (3.1) is 00.0 and GPA is 0.000. That is 25 * 4 = 100.0 but in RPG with (3.1) it looses the 1 and is 00.0 This would be very bad.... Phil
    51,365 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