On 17-Jan-2012 11:54 , M. Lazarus wrote:
I am working with a flat file, originally created as a 36EE file.
The catch is that it contains multiple record formats, so I can't
just convert it into a standard PF file.
Linked with an IDDU definition, or just treated by programs as
multi-format, irrespective of [the IDDU or DDS] external definitions?
If not linked, and further dependent on how the file will be
utilized, the following effect could be compatible across all of the
formats because the Packed BCD column is not protected from bad data;
i.e. if an alternate format chooses to store non-packed data there,
should be no problem to those using those formats.
R FLATLIKE
PFX 24A
QTY 5P00
SFX ##A
A Multi-Format LF to the rescue, right? I'm running into a situation
where the record contains packed data.
A QTY I SST( F00001 25 3 )
makes QTY into an alpha field.
A QTY 5P 0I SST( F00001 25 3 )
does not seem to be allowed:
CPD7410 Message: Characters in indicated field not allowed.
Is there some way to map the resulting alpha string into a numeric
field in the LF's DDS?
There is no "direct map" capability to define a DDS logical [derived]
field with a type\len over the raw [bytes of] data; just as with SQL :-(
A logical field typed as P[acked] can be defined only over a Date or
a[nother] numeric data type; CPD7928 "Data type from physical file not
converted to type specified." A keyword like RAW()\DMAP()\MAPSTG()
which could replace the SST() and allowed B[oth] specification for I\O
is something like I had alluded should be made possible back in V1, in
order to enable a more direct transition from MFPF to MFLF. I would
also like similar capability in the SQL, and available to the first
argument of CAST or a similar builtin. I would not expect either to
ever happen; the former because SQL is the direction [away from flat],
and the latter both because the SQL has no concept of un-typed data
[with the closest capability being from the HEX scalar] and a User
Defined [Table or Scalar] Function can suffice to take the effectively
untyped flat file data and represent any datum as a value of any
supported SQL type however the creator of the function deems appropriate.
_i Data type for physical and logical files (position 35) i_
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/rzakb/ldata.htm
"
...
The following table shows what types of data conversion are valid
between the data types of physical and logical file fields, where valid
conversions are marked with an X or with a reference to the table notes:
...
"
Instead of using a DDS LF there is the option to, just like with a
program described file, let the program define those bytes as packed BCD
data. Moving the physical data into two or more physical files with
formats reflecting the separate record formats should allow a MFLF to be
built to replace the MFPF.
Without knowing the full extent of what would need to be done with
the files and data given an alternative view and possibly alternate
storage, and what restrictions existing applications would have for
their access to the files and data [with original names and structure],
suggesting what might be used as alternatives would seem to be little
more than just "throwing things against a wall to see what sticks."
That is, there are multitudes of ways to make the data available in the
format desired, although inferring which might be better than another
requires knowing both what must remain unchanged and what can change.
For example, if the origin of the message is to resolve just a simple
case of "I want to query for read-only, the data from the flat-file,
from just one particular format, as if the data described by the
equivalent DDS logical specification SST( F00001 25 3 ) in that format
represents a DEC(6) column named QTY", then there are plenty of existing
examples. Although with the definition of the record ID code selection
for the format which should have QTY, and noting if support of any
negative or any non-preferred BCD sign nibbles need to be recognized, I
could code something specific in response. Or more generically, there
are [and someone could respond with] UDF examples.
Regards, Chuck
midrange.com
