RE: Thoughts/experiences with JSON/XML on DB2

Looks like Vern beat me to the structured vs. non-structured data thing, and I agree that 25 record formats seem a bit much. But it is likely that there is a single header type record, one file. And then multiple detail record types that could probably be combined into a single detail file. Maybe some comment record formats, another one or two files depending on how you approach that. It is also possible that your order has some total records that add nothing to the order. Those could just be dropped in favor of calculating totals on the fly.

Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx


-----"Mark Murphy/STAR BASE Consulting Inc." <mmurphy@xxxxxxxxxxxxxxx> wrote: -----
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
From: "Mark Murphy/STAR BASE Consulting Inc." <mmurphy@xxxxxxxxxxxxxxx>
Date: 04/01/2016 11:56AM
Subject: RE: Thoughts/experiences with JSON/XML on DB2


Ahh... there's the problem.

S/36 files contain structured data, not unstructured. The record structure on the S/36 is defined in each program, and while that allows you to have multiple record formats in a single file, each record format has a very specific structure. The appropriate way to deal with this is to split the multi-format file into multiple single format files, one for each record format.

Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx


-----Justin Taylor <JUSTIN@xxxxxxxxxxxxx> wrote: -----
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
From: Justin Taylor <JUSTIN@xxxxxxxxxxxxx>
Date: 04/01/2016 10:18AM
Subject: RE: Thoughts/experiences with JSON/XML on DB2


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?