Re: Controlling the definition of fields defined like(...)

Rick,

Sorry about the looonnnnggggg time getting back to this but other coding
pressed this issue to a workaround till now.

/include MiniRant :-!

Using an E DS does indeed define the field exactly as it is in the file.
That is why you can do IO operations into a E DS and it works. It will
do for this project for now. The problem is if I need to do other DS
work on the field(s) that isn't a simple %SUBST(...) or concatenation of
already adjacent fields I will have to do field movements. The movements
wouldn't be needed if when doing a LIKE(...) we could specify storage
type override the same as we can override length with +#, -# and I
wouldn't need the E DS. _After all we are defining new fields not (as
far as the compiler should care) another name for the same storage._

What is so aggravating is that depending on whether you have the based
on field in a PF and/or DSPF and the phase of the moon it is seemingly
unpredictable whether the field is packed or zoned without regard to how
it is in the PF. True any given program always compiles it to the same
type but there doesn't seem to be human recognizable rules as to if you
have it here or there it will be such. I have two programs with the same
PF but of course different DSPFs and other (non DS) usage and one
compiles to packed as in the PF and the other compiles to zoned. The
only consistent way right now is the E DS.

I would have to dig it up or do some experiments but I seem to recall
that if you overlay a numeric field onto an alpha (perhaps the other way
around) the compiler would force the numeric to zoned (unless you used
from/to/type or LIKE) so the alpha would be a relatively accurate
(unless the number was negative) string representation.

What is so hard for the compiler owners to provide this extra step when
they already have LIKE(...) BUT...? All I really want now is to say this
new field that is LIKE(...) is packed or zoned, but I can see where I
might want to say LIKE(a numeric) but alpha (+#) to setup for an edited
version of the field to put into (CGIDEV2, STRMF, something in the
future, ...)

Roger

On 6/14/2006 9:06 AM, rick baird wrote:

Roger,

if you don't specify the specific type of a field in a data structure
the default is packed, as all numeric data is eventually converted to
packed for manipulation and math.

which has gotten me to thinking, maybe I was backward about what
defining the eDS does - I think it describes it specifically as how it
is in the file (packed, zoned) whereas only having the field described
by the F and input specs will aways declare it to the program as
packed.

try this.  add an eDS for file C to both programs and see if it fixes
your problem.

On 6/14/06, Roger Vicker, CCP <rv-lists@xxxxxxxxxx> wrote:
  

Rick,

More Details.

PFile C:
    Field dividnum is 5p 0

DSPFile B:
    Field dividnum is reffld(dividnum C) which compiles as zoned.

Program A:
    F spec for pfile C
    DS as in original post (below)

Program B:
    F spec for dspfile B
    F spec for pfile C
    DS as in original post (below)

In both programs the array is defined as like(dividnum) and in a DS but
in program B the compiler makes the type as packed. I thought that
unless you specified the full attributes of numeric field in a DS the
compiler would zone type it. I even tried defining a dummy 1A field as
an overlay of the sel array in program B to hint the compiler to zone it
and the array is still packed.

Also, in checking the compile listing for both programs the field
dividnum is zoned in A and packed in B just like the array.

Roger

On 6/13/2006 9:53 PM, rick baird wrote:

    

Roger,

If I understand the problem correctly, you have a field defined as
zoned because it's defined like a field in a file, and another as
packed because it's in a DS.

try this: in the program that has the zoned field, in addition to the
F spec, define the file as an external data structure.  you don't have
to do anything with it, but I think (i know, trouble), it will map all
the zoned fields to packed.

I don't know if you can define a display file (you did say it was a
display file, right?) as an eDS, but if not, if a similar field is
also defined in another file, define that file as an eDS and use that
field for your like().

hope this helps,

Rick

On 6/13/06, Roger Vicker, CCP <rv-lists@xxxxxxxxxx> wrote:


      

This is starting to drive me down the hall screaming.

And the archives had a promising solution with data structures but it
just doesn't work. V5R3

I have a file with a field (dividnum) defined as packed 5,0.

I have two programs that use the file. Program B has a display file with
the field in it via reffld(dividnum)

Program A has a data structure defined with a specified length and an
array in it defined as like(dividnum) that is passed to/from program B
using prototypes.

Program B has a data structure defined with with the same specified
length and an array in it defined as like(dividnum) that is pointer
based. Program B sets the pointer to the data structure as the address
of Program A's data structure that is passed to it. I have verified that
the pointer "magic" works just fine.

// Program A

D SelDs           ds           384

D   sel                               like(dividnum) DIM(32) ASCEND


// Program B

D SelDs           ds           384    based(SelDsAdr)

D   sel                               like(dividnum) DIM(32) ASCEND

D SelDsAdr        s               *


The problem is that the array in program A is zoned, as I would expect
it to be since it is in a data structure. Program B however defines the
array as being packed.

There has got to be a way to define fields by reference to reduce code
changes when lengths changes but either get consistent type (zoned,
packed...) or be able to force the type so that they can be passed as
parameters between programs.

Does everyone hard code field lengths for numeric parameter passing or
have I missed something?

Roger Vicker, CCP

--
*** Vicker Programming and Service *** Have bits will byte *** 
www.vicker.com ***
Never deprive someone of hope, it may be all they have.

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.




        

--
*** Vicker Programming and Service *** Have bits will byte *** 
www.vicker.com ***
Never deprive someone of hope, it may be all they have.

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.