|
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.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.
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
