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

I am not really complaining about the compiler writers setting up the
program's internal storage for a field by their rules when dealing with
the external definitions being varied. And I have found (the start of my
problem) that they don't always use packed by default. If they did alway
use packed I wouldn't have the base problem. But, with out telling the
compiler more than I should have to, I can't tell it that I have a good
reason to override part of their rules.

My rant was that when I need a numeric field to be a specific storage
(for whatever reason but  in this case to pass as a parameter) I can't
without specifying the length and using a DS. Even (and where I started)
when doing a LIKE(...) definition. All I want is to have the most key
attribute (length and char/number) defined in the database and be able
to reference it everywhere else (including RPGLE) with exceptions such
as longer/shorter x digits and zoned/packed the same as we can in DDS.

Roger

On 7/8/2006 11:40 PM, Alan wrote:

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.
    

Maybe I missed something but the rest (snipped) seemed an objection to 
the seeming random nature of storage types (zoned, decimal, etc.) for 
fields coming into the program from externally described files.

I didn't catch the thread on that before, but I can see some sense for 
the compiler writers to doing their field definitions by certain 
invisible rules, outside of having them specified as part of an 
externally described DS.

You could have a field defined in a DSPF as zoned, in one PF as packed, 
another a zoned, and so on.  The same name can show up, theoretically 
speaking, twenty times. And theoretically, there could be five such 
fields lined up contiguously in one file but in opposite order in the 
other file!

Therefore they cannot guarantee you something they have no control over, 
so instead I'm sure (at least I hope) they've been defining these fields 
in the most productive and efficient manner available, and by making 
numeric fields packed by default they saved conversion time in 
calculations.

I think it's a lot better design than the RPGII, where you could put the 
same name of a numeric field in a dozen different data structures, such 
that when you changed the field in the calcs the compiler writers had to 
copy the value to several storage locations. (IIRC).

---Alan