RE: Questionable practice in file handling in CL

I remember a time or two where that was a problem (back in the day), and "once burned...". I get it.

Newly discovered information now has the file ranging from 20K to 500K records, and when working with 20K and that lower range, the entire reason for the logicals may be moot. However, the 20K will eventually be 520K as the processes will be combined and hopefully will grow from there.

Also, the logicals are needed immediately following the process to rebuild them, so deferring is probably not a time saver.

Now I'm wondering if the entire process should be re-developed and modernized. In the words of the old commercial "there's got to be a better way!" (yeah, I'm that old, and I watched way too much TV... back in the day.)

There's way too much about this that I've not put into the equation for a proper decision to be made via this venue.

Thanks again.

Duane



-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob Berendt
Sent: Monday, October 23, 2017 11:30 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: RE: Questionable practice in file handling in CL

I had an old article from at least a decade or two ago that said that this was pretty much obsolete. It agreed that it did used to be a concern. And previously it was recommended on a large file initial population to remove the logical files and add them back at the end. But it was no longer a concern as of V (something or other) of the OS.

However, there are those who beg to differ and say they have even some recent experiences that this is not totally resolved.
One person in this thread did notice a "slight" increase in run time on large files but their most recent comparison was at 6.1. And it was not noted if they included the build time of the access paths of the LF's in this run time.
One person noted his concern about paying the penalty later with a delay rebuild on the access paths and if it was beneficial with all combined.
One person noted that changing the maintenance on the LF's to deferred, adding the rows and then changing the LF's back to immediate (with parallel jobs) was faster. Perhaps an access path rebuild is more efficient than maintaining the access path upon the addition of each row.
This person did not mention when they had this experience however. Perhaps hardware and OS have changed since then?

I keep thinking back before we saved access paths on our saves on how we were literally locked out of some files for almost a week during a restore while it was rebuilding access paths. So, these access path times can be substantial. So deferring them until needed may not always be the most popular idea. IBM changed the defaults on saves to save access paths since then. Too many people got burned. That and media speed and volume has substantially increased since then.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Justin Taylor <JUSTIN@xxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 10/23/2017 11:10 AM
Subject: RE: Questionable practice in file handling in CL
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



I don't see a reason to do that now. It sounds to me like a S/36
throw-back.



-----Original Message-----
From: Duane Scott [mailto:dscott@xxxxxxxxxxx]
Sent: Friday, October 20, 2017 1:39 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Questionable practice in file handling in CL

I'm looking at a CL that:

1. deletes the 6 logicals on a single physical file
2. deletes the physical file
3. recreates the physical from the DDS
4. runs an RPG program that writes (20k to 30k) records to the physical
5. recreates the 6 logicals

The only explanation I can come up with is that it once was thought that
the system would be faster if the logicals were built one at a time after
the physical was built rather than during the running of the RPG program.

Does anybody have stats to back this up.

I think it's not needed and that a CLRPFM on the physical is all that
would be necessary and allow each logical to remain during the run of the
RPG build program.

Duane