× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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?

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.