Re: Zoned fields showing as packed

[qsrvbas@xxxxxxxxxxxx]

rpg400-l-request@xxxxxxxxxxxx wrote:

>    5. Zoned fields showing as packed (Bob P. Roche)
>
> A co-worker had a problem, that I haven't seen before, maybe there is a 
> PTF for it. He has a file with a field defined as 9s 0, we can verify it 
> in several places. When he tries to use that field in a prototyped call , 
> also defined as 9s 0, he get a compile error - The type and attributes of 
> the parameter do not match those of the prototype. RNF7535. looking at the 
> source everything is fine. Looking at the compile listing, The field in 
> question is defined as 9s 0 everywhere until the global field references 
> section when it shows as P(9,0). 
> Has anyone seen this before? For now he added CONST to the parm, The value 
> is not going to be changed so this converts it under the covers, but it 
> should work without that. 

Bob:

There might be multiple ways around this, depending on the exact 
circumstances. The ways I use involve LIKEREC() or EXTNAME(...:*INPUT).

A couple demos might be useful:

These use the QCUSTCDT file that's distributed in the QIWS library 
of most System is (i's?).

     h dftactgrp( *NO )
     h    actgrp( *CALLER )
     h debug

     fQCUSTCDT  IF   E             DISK

      /free
       read(e) CUSREC                                       ;
       dump                                                 ;
       eval *inlr = *on                                     ;
       return                                               ;
      /end-free

That one is purely for the value of its compiler listing. Even 
though the numeric fields in QCUSTCDT are defined as zoned (S), you 
can verify that they show up as packed (P) in the way RPG compiles 
its work spaces for them.

This next one shows a way to get around that behavior:

     h dftactgrp( *NO )
     h    actgrp( *CALLER )
     h debug

     fQCUSTCDT  IF   E             DISK

     d nullptr         s               *   inz( *null )
     d recDS           ds                  likerec( CUSREC )
     d                                     based( nullptr )

     d demozip         s                   like( recDS.zipcod )

      /free
       demozip = 98332                                      ;
       dump                                                 ;
       read(e) CUSREC recDS                                 ;
       eval *inlr = *on                                     ;
       return                                               ;
      /end-free

This program will crash when it tries to execute the READ because I 
never give any memory to the DS. It doesn't matter, though, because 
the DUMP op-code has already produced what we need. We can see what 
DEMOZIP looks like in memory.

It has a DS that uses likerec() to obtain the field definitions from 
the file. The DS is based() over a pointer that's simply null. No 
memory is allocated for the DS; only memory for the null pointer is 
used.

However, I wanted a zoned representation of just the ZIPCOD field. 
Maybe I needed it because I was going to overlay the value with 
another field definition. But I didn't want to hard-code the 
definition in case it changed in some database re-design next year.

If I had defined DEMOZIP as LIKE(ZIPCOD), it would come out as 
PACKED(5 0) even though the ZIPCOD in the file isn't packed. But 
when I define it according to the DS definitions brought in with 
LIKEREC(), it magically becomes ZONED(5 0).

Somewhere recently on this list (I think) there was a more 
authoritative explanation that _helps_ in understanding why this 
happens. For me, it's enough for now to know that this is simply the 
way it is.

Tom Liotta