Re: Converting large amount of data

[x y <xy6581@xxxxxxxxx>]

WRT creating LF's afterward: one school of thought is to create the
highly-used LF's first; depending upon your journaling setup and recovery
configuration, you might be able to get back on-line faster after a crash
because the most popular LF's will be recovered first.

I usually sort my key fields and create them based on the number of
keys--the files with the largest number of keys are built first.

If you have any SQL indexes over a PF, build them before LF's: the SQL page
size is larger (64K) and allows a bigger bite of the data.  Logical files
will share SQL indexes where possible.

On Fri, Jan 22, 2021 at 10:06 AM x y <xy6581@xxxxxxxxx> wrote:

> Copy data into PF's without logicals, SQL indexes, or constraints
> (referential integrity and such).
>
> In CPYF, use FROMRCD(1) and COMPRESS(*NO) to try to force the system to do
> a block copy.  You mentioned "new format", so you'll probably use
> FMTOPT(*MAP *DROP); don't use it unless you need to.
>
> WRT "new format", remember you can change your DDS source (multiple
> columns at once) and then execute CHGPF (including the DDS source file and
> member names) and the system will change the format for you; it's the
> equivalent of SQL's ALTER TABLE.  *My experience suggests the logicals
> are magically maintained through this process; this can be a major
> time-saving benefit*. So, if you need to add new columns, resize others,
> change the text, edit codes, or column headings, CHGPF is the way to go.
> I've been midranging since the days of the System/3 and using CHGPF to
> change the layout of a file is IMO one of the top five enhancements ever.
>
> On Fri, Jan 22, 2021 at 8:27 AM <smith5646midrange@xxxxxxxxx> wrote:
>
> > We have some files that are pretty big that we are going to be converting
> > to
> > a new format and I'm looking for some info on converting the data.
> >
> >
> >
> > I am not looking for answers about splitting in threads or anything like
> > that.  We are converting over 700 files so threads will not help me.
> > Threads will just delay other files from being converted.
> >
> >
> >
> > That said, I have one specific question that I am looking for an answer
> > on.
> >
> >
> >
> > Is it more efficient to
> >
> > 1.      Create the new physical files and their logical files, and then
> > convert the data
> >
> > or
> >
> > 2.      Create the new physical files, convert the data, and then add the
> > logical files
> >
> >
> >
> > I know the machine has 3 CPUs with the ability to pull 3 more from the
> > pool.
> >
> > I forget the memory but it is a pretty decent amount
> >
> > There are 12 I/O channels.
> >
> >
> >
> > If there is something else you need to know to give me an answer, please
> > ask.
> >
> > --
> > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> > list
> > To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit: https://lists.midrange.com/mailman/listinfo/midrange-l
> > or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
> > Before posting, please take a moment to review the archives
> > at https://archive.midrange.com/midrange-l.
> >
> > Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
> > questions.
> >
> > Help support midrange.com by shopping at amazon.com with our affiliate
> > link: https://amazon.midrange.com