Decimal-data error.

[argasoft36]

Hi!

In my address file I have a headquarters key which can be equal or different to the unique key.
They are defined as follows in the PF

A            ADDRKEY      5S 0B
A            HDQRTKEY     5S 0B

If I see at the PF listing it seems correct, i.e. I read '00001' (e.g.).

If I CALL a programme to display infos about the headquarters address (in case ADDRKEY NE HDQRTKEY), I do the following:

C                   CALL      'HDQRTSMNT'
C                   PARM                    COMPANY 
C                   PARM                    HDQRTKEY

and in the CALLED HDQRTSMNT

C     *ENTRY        PLIST                                        
C                   PARM                    COMPANY        30  
C                   PARM                    HDQRTKEY        5 0

At running, Decimal-data error is shown.
The DUMP print shows me a value like

HDQRTKEY            PACKED(5,0)           0 0 .           'F0F0F0'X

Of course, in the CALLER the address file is UF and in the CALLED it's IF in the F-specs.
What am I doing wrong?

TIA
Arnaldo

[tomholden]

Re: Decimal-data error.

in the CALLED HDQRTSMNT you are trying to received PACKED decimal. either change the calling program to pass a packed decimal or change the called program to accept zoned.

[argasoft36]

Re: Decimal-data error.

Thanks, Tom!

I'm aware the CALLED one is reading a packed numeric (as per DUMP), but why, as it's defined (see DDS) as zoned numeric and written accordingly ('00001' in the file)?
ADDRKEY and HDQTRKEY fields are not redefined anywhere in the programme.

I just have the following for the address file:

DINPADDRESS  E DS                  EXTNAME(ADDRESS:ADDRESSREC)
D  ADDRFISC1                     3    OVERLAY(INPADDRESS:495)    
D  ADDRFISC2                     3    OVERLAY(INPADDRESS:498)    
D  ADDRFISC3                     5    OVERLAY(INPADDRESS:501)    
D  ADDRFISC4                     5    OVERLAY(INPADDRESS:506)

to have four input fields on the screen for a 16-byte field in ADDRESS file without having to code lines of MOVE to/from an array to split and group again.

I compile using opt 14 in the PDM and with FIXNBR set to default value.

TIA
Arnaldo

[tomholden]

Re: Decimal-data error.

in the called program it's redefined by virtue of adding the field definition on the *ENTRY. take off the "5 0" from the variable on the PLIST and it will pull the "true" definition from the PF. FWIW i would avoid using FIXNBR at all times unless there's something that will actually require it (which there shouldn't be that many and I can't think of a reason off the top of my head) FIXNBR can cause you a lot more headaches than you want to deal with FIXNBR <> IGNDECERR (which is a big enough pain to avoid, it's better to plug the holes in your programs & correct the invalid data than to continue with the kludge)

[argasoft36]

Re: Decimal-data error.

Hi, Tom and Thanks.

I've done as per your advise: now it looks like this (COMPANY is also already DDS defined)

C     *ENTRY        PLIST                                        
C                   PARM                    COMPANY        
C                   PARM                    HDQRTKEY

but error message remains.

I never meant to work with FIXNBR or things like that.

The compiler listing of the CALLED programme shows

246=I                             S  472  476 0HDQRTKEY

Thank you for any hint.
Arnaldo

[tomholden]

Re: Decimal-data error.

make sure that the calling program doesn't have anything redefining the variables (i.e. display files, DS, etc) you can look at your compile listing and determine that if you don't want to hunt and peck for it. anytime you specify field length & decimals on a C spec the field will always be defined as a packed decimal (just an FYI since we kinda covered that already). FWIW never define a field in the C specs, there's just no reason to & you'll end up with scenarios like the one you just encountered, best practice is to define once and do it in your D specs...

[tomholden]

Re: Decimal-data error.

also...if you can include the compile listing in the calling program as well ( both I and O specs) would be helpful.

[argasoft36]

Re: Decimal-data error.

Thanks again.

Enclosed compiler listing. I've made some note to clarify what I want to do.

Don't be disconcerted by my writing style: as already told I come from S36 (developed and used travel agency software) so some thing may be deprecated and or redundant and I still have to get acquainted with D-specs.

TIA for help and time.
Arnaldo

[tomholden]

Re: Decimal-data error.

i haven't forgotten about you but i really haven't had time to look at the compile listing. first thing i would check though is in the called program look for all occurrences of the parm field giving you the problem and see if it is redefined on any other C spec where it is used as a result field ( i really abhor C spec field definitions because of this type of thing). we are starting a conversion of our financials package and don't have time to actually dig thru the compiler listing perhaps someone else can pick up the ball if this suggestion doesn't fix your issue.

[argasoft36]

Re: Decimal-data error.

Hi!

Thanks in any case.

I suppose numerics are just passed packed, as there's no field definition of "trouble variable" in the C specs.
Latter is just defined as said with DDS for PF and and to PF related DSPF and nowhere else.

Will try a turnaround.

Arnaldo

[argasoft36]

Re: Decimal-data error.

Hi.

Just for you info: I found this http://www.code400.com/forum/archive...hp?t-5082.html.
It's dated 2008 and talks about RPGIV, but I'II try to work around using a "work variable".
I searched a lot at IBM but I did not find a note that says that numerics are passed always as packed.

Arnaldo

[Rico]

Re: Decimal-data error.

Arnaldo,

Make sure any numeric fields in your display file are initalized before you EXFMT or READ the display file.


Rico

[Scott Klement]

Re: Decimal-data error.

The trouble here, I'm guessing, is that RPG will sometimes define fields as packed, and sometimes define them as zoned, unless you explicitly define the variable with a P or S in the D-spec (or DCL-X in the new "all-free" syntax.)

It will often define things differently than what is in external file definitions. So an external file may be zoned, but RPG will convert it to packed automatically.

So this makes it easy for one program to have the variable defined as zoned, and another to have it as packed. When it's passed as a parameter, you will get the decimal data error since the definitions don't match.

So, like others have said, make sure it's defined the same way in both programs. You can do this by checking the compile listings to see (in the cross-ref at the bottom) what RPG has defined the fields as. Or you can use the outline view in RSE for the same purpose.

Or, better yet, use a prototype and procedure interface instead of the old, clumsy, PLIST approach. On the prototype and PI make sure the data types are given explicitly. Then RPG will either make sure the variable is in that format, or will give you an error if it is not, either way, this makes it clear what's going on.

[argasoft36]

Re: Decimal-data error.

Hi and thanks a lot!

I've checked each field definition/modification reported in the compiler listing of calling and called programme:
- in the I-specs taken from DDS the fields are with 'S'
- there is a Z-ADD ADDRKEY/HDQRTKEY to ARRAY(n) and array is defined as '5S 0', length of course equal to fields
- there's also a Z-ADD ARRAY(n) to ADDRKEY/HDQRTKEY
- of course they read the same DDSs, so definitions are (?) the same

No redefinition in the D-specs.

So I made like this (Tom abhors it, but it runs):
- before calling Z-ADD ADDRKEY/HDQRTKEY to ADDRKEYPKD/HDQRTKPKD 5,0
- after returning to caller Z-ADD ADDRKEYPKD/HDQRTKPKD to ADDRKEY/HDQRTKEY

I'm new to ILE and come from years and years of RPGII (BTW, I do not remember any of these problems in those days), so prototypes are just science fiction for my actual level (but thank you Scott).

How would be the code ot D-specs? My DSPFs are related to PF.

TIA Arnaldo

[Scott Klement]

Re: Decimal-data error.

I've checked each field definition/modification reported in the compiler listing of calling and called programme:
- in the I-specs taken from DDS the fields are with 'S'

Please ignore the I-specs and DDS. It's the RPG definition that's important here, not the DDS definition. RPG will automatically translate most fields to packed on-the-fly. (I said this in my previous message, too, but maybe you missed it?)

I know that the compile list you posted earlier is no longer up-to-date, since you've changed things since then, but here's an example of what I mean:

72=I                             S    2    6 0ANACHIAVE     <- I-specs are zoned

. . . later in same compile list, you see this...

         ANACHIAVE            P(5,0)           72D  108M 144M 180M
                                               216M 442

So, while the I-specs and DDS show this field as zoned (note the S in the I-spec), the RPG program has it defined as packed (see the P(5,0) near the bottom). So this is what I'm trying to tell you... RPG will redefine the fields as different types. They will be packed unless it has good reason to make them zoned (such as a conflict with another field).

Please check the cross-reference at the end of the RPG compile listing to see what data types it's using. Make sure the caller and called program (by checking the data types in BOTH places) are using the same definition.

I'm new to ILE and come from years and years of RPGII (BTW, I do not remember any of these problems in those days), so prototypes are just science fiction for my actual level (but thank you Scott).

??! Are you saying you're not capable of learning anything unless it's at least 20 years old? (Prototypes were added to RPG in 1996, which is only 18 years ago, so you can't learn them?!)