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!!

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

I’m really, really old but I wasn’t on the 400 when this type of code was written.
Phil

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

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

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.

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

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.