× 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.



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



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.