Re: how to sort a file in place?

On 23 Jan 2013 12:22, Dan Kimmel wrote:

CRPence on Wednesday, January 23, 2013 2:04 PM wrote:

<<SNIP>> And being a LIC implementation rather than an OS
implementation detail, that is at least somewhat irrelevant
because user code both remains blissfully unaware and can not
incorrectly code dependency upon an implementation detail that
might change. <<SNIP>>

It's that "blissfully unaware" part that I think is important.

Regardless of the LIC implementation, the user code can take advantage of an arrival access path that, since the completion of RGZPFM KEYFILE(named) ALWCANCEL(*NO) without any further I/Os [that would impact the assumption], will return records in the order of the "named" access path. That is because that specific ordering is the documented atomic and synchronous outcome. User code can be aware and dependent upon that as fact. User code need not have any concern for improper dependence upon any implementation detail, about how the LIC accomplishes its task.

Physically ordering the records as you describe is only going to
materially impact performance in batch jobs that process the file
front-to-back in that sequence.

What defines "to materially impact" is important. But... The positive effects for performance are not limited only to batch, nor even the sequential access method.

Using keyed [random] access method for the purpose of effective sequential access, i.e. via the same [or leftmost key(s) of the] index for which the physical order was previously established, will also gain a performance benefit as a side effect of the physical reorganization. That is because a page in memory from the physical I/O for the current row is more likely to be the same page in which the next row resides. Thus the "random access" method becomes less so; and can see gains for traversal in either direction. Of course the benefit would be diminished, as changes are made to the keyed data; i.e. the "random access" becomes more random, for the location of the actual physical row data.

But if the cost of a RGZPFM is accounted in the overall "material" effectiveness, then rarely is the cost of the reorganized data going to pay off, except in very specific scenarios, and likely only those scenarios involving a significant number of passes reading the ordered data. Basically, if there is sufficient of each storage, CPU, and time allowance for the data being offline, in order to effect the reorganization, then what should be known: Do those costs justify whatever performance gains in reading the data the planned N-times?