Re: You know, I'm pretty sure it's zoned...

R Bruce,

>Maybe, but it's been more than just a couple of times and it's more than
>just annoying after this many years.

So you're a slow learner besides, huh? <gr&r>

>> You see, you did *not* explicitly show an intent for the RPG field to be

>OH YES I DID! One declaration. And that's my issue.

I'll be pedantic and repeat a DDS declaration does not imply intent for RPG to
create a zoned field -- *especially* in the case of DSPF vs external database
definitions -- unless you use an externally described data structure.

>Fine, give me a warning. I can deal with discrepancies and conflicts between
>fields, it's the single decalaration that gets modified that I have a
>problem with.

To be repetatively redundant, it is not a single declaration that gets modified.
If you're not using a externally described DS, the storage type for RPG was
never declared.  I know you don't see it that way, but thinking of it that way
has always worked for me.

>Funny, they don't need to be packed because I don't do math on those
>numbers. But I sure do a lot of displaying and printing and updating.
>And sorry, but the client won't let me forget display files.

Surely you have lots of database fields which are packed, yet you are still able
to do displaying and printing and updating of those too.  In fact, you can even
have a DSPF use REF() or REFFLD() and name a packed field and it will modify
your explicit declaration and not make it packed in the DSPF/PRTF.

The point is that to RPG, the DSPF is like that reference file.  It takes on
attributes like the number of digits and decimal positions, but ignores the
distinction between packed and zoned.  That to me is no different than how DDS
will ignore the packed/zoned "intent" of a referenced field when creating a
display or printer file.

>Ditto. So why have free format? It wasn't there in the beginning.

And it doesn't break backward compatiblity either.  Changing the compiler rules
so that zoned/packed storage type of non-DS fields is derived from the DDS can
break existing code when it is recompiled.  Do you really want that?

>so, you must have had a different machine than me... <VBG>

Fat finger syndrome...

>No, the choice of packed decimal is a 38 thing. Again historical. The 38 had
>a decimal processor and performed best with packed decimal arithmetic.

The choice of packed vs zoned is a 38 thing.  But the choice of RPG using a
different working storage format from external format is not new to the 38.
Other S/3x machines performed best with zoned decimal fields, but that is beside
the point.  The point being that referenced fields have *never* implied intent
between zone/packed.

Think of all the programs which use reference packed database fields in a
DSPF/PRTF.  Do you really want a warning message for each one?  Don't you think
it would be ignored as much as a 7030 error?

Doug