On 19-Mar-2012 05:52 , Charles Wilt wrote:
On Sat, Mar 17, 2012 at 12:39 PM, CRPence wrote:
<<SNIP>>
Given a capability for the logical file [DDS or SQL] to
/direct map/ the data in the underlying physical buffer,
irrespective of the PF fields, plus those logical files
being able to retain all I\O capabilities beyond read-only,
then a direct transition from the MFPF to an equivalent MFLF
would be much easier; alas, no can do.
http://archive.midrange.com/rpg400-l/201203/msg00161.html
I didn't follow any of that. :)
FWiW:
A SQL SELECT can effect the /mapping/ [i.e. casting] of 2-bytes of
CHAR FOR BIT DATA string data from the faux-field PGMDESC in the
database flat file PGMDESC, into a DECIMAL(11,2) using a scalar UDF; e.g.:
SELECT A02toP11_02(substr(PGMDESC, 3, 2)) FROM QTEMP/PGMDESC
However that same SELECT can not be used in a CREATE VIEW because the
file named on the FROM clause is not externally described. Even if
possible, the column in a VIEW would be read-only, leaving unresolved,
any similarly simple column definition as solution for update-capable
access.
A CRTLF from DDS similarly can not effect the same conversion as the
SELECT, from a binary character string of two bytes into a P(11,2) [or
even P(3,0)], from data in a database flat-file. However the CRTLF can
not, because of both an inability to conjure field names and a limited
set of defined /mapping/ from one type to another; plus, the SST as a
means to identify byte positions requires /input-only/ as with a UDF.
There is a table that "shows what types of data conversion are valid
between the data types of physical and logical file fields" and there is
no support to derive Packed Decimal from character data:
_i Data type for physical and logical files (position 35) i_
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzakb/ldata.htm
And while the character to zoned decimal numeric _is allowed_ in a
DDS LF [per that table in the doc], the conversion is documented to be
supported only from the EBCDIC digits 0xF0 to 0xF9. However that
mapping capability\feature is implemented as an effective "direct map",
where the /zoned portion/ of each digit is ignored [assumed to be 0xF]
except the sign-digit which correctly accepts 0xD0 to 0xD9 and 0xB0 to
0xB9 as representing a negative value. Since that effect is an
implementation detail, what is documented might best be inferred to be
the maximum of what is actually supported:
_i Conversion between zoned decimal and character ... i_
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzakb/convzdec.htm
The link to the archived message gives a setup for a very simple
example of an attempt to achieve mapping of raw BCD data into a P(3,0)
field. The example leaves unstated, any LF-DDS which could solve the
problem... because presumably, there is no DDS that can.
If DDS-LF CRTLF could solve that problem, then converting a flat-file
into an externally described file could become much simpler [given the
additional capability to conjure field names without a join]. There
would be no need to decide how the physical data must be described and
then copied to one or more files as required by a MFPF definition having
conflicting, overlapping, or empty\undefined storage across different
record types\ID-codes. That is because the MFLF would be able to map
fields directly over the data in the physical buffer [by byte positions,
versus over typed field data, where the former is a /direct map/ of the
physical data into a named and typed field] and adding Select\Omit to
implement the Record ID codes for the Record Format that owns\defines
those rows of data. With all of that, the MFPF could be translated
directly into one MFLF while the MFPF remains unchanged.
Regards, Chuck
midrange.com
