Re: Thoughts/experiences with JSON/XML on DB2

He may be referring to a TABLE FILE. These were common in the S/3 (dating
myself) and S/36 days.
This type of file normally has a common key field which is the table name
and a code with the associated values as the data portion. The program
would then get the record and load the data portion into some other
structure that corresponded to the actual data.
To create external files from such a flat file would require only 1 file
per table file name.

Jeff Young
Sr. Programmer Analyst

On Fri, Apr 1, 2016 at 11:51 AM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
wrote:

Hi Justin

Just to clarify - is this a PF (physical file) or an LF (logical file)?

When you say multiple format, some might be assuming an LF - but it's
probably a flat file with different formats.

OK, so each record will have 1 or more record identifying codes - this is
used in the RPG I-specs to tell you which one you are using. The F-specs
can tell you where and how long the key is - then you'd need to find out
from the I-specs which fields are in the key.

You mentioned there are 25 formats in this file - that seems way too many
- typically these are header/detail/extended-detail kinds of things.

Look at the record-identification entries in your I-specs - those tell you
how many you have - in fact, your F-specs should tell you how many.

You COULD do SQL by using this identifier in a WHERE clause - then having
substrings of the entire record based on the format for each identifier -
YUK!!

You call it "non-structured data" - I must disagree, and I think that took
you down a curious yellow brick road - it is a flat file with several (25?)
unique structures, 1 per record.

So your columns come from the I-specs, the index comes from a combination
of information in and F-spec and the related I-specs - ba-da-bing! EZ-PZ!
Right?

HTH
Vern

On 4/1/2016 9:18 AM, Justin Taylor wrote:

Booth Martin:
--This is live data with new records being added daily.
--Extracting the non-structured data into a traditional RDBMS was my
first thought. Then I thought that a NoSQL type approach might be better,
since NoSQL was originally intended for use with non-structured data
(although the authors probably never considered S/36 files).
--I'm not sure either type of extraction would be significantly more
difficult than the other.

Rob Berendt:
--"Multiformat join logical file", those emulate the multiple record
formats seen in S/36 files, correct? Does SQL support those?

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.