RE: How to re-org an empty file

Thanks Chuck, I enjoyed reading that, aspects of the database that I had not dealt with before.
Paul Therrien
Ext: 551


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Thursday, March 29, 2012 2:34 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: How to re-org an empty file

On 29-Mar-2012 07:07 , Paul Therrien wrote:

INZPFM is an interesting command. I didn't know it existed. And the
idea that one could initialize with deleted records seems odd. It
almost seems to be too specialized of a command to be part of the
operating system. (This is just me musing.)

A side effect of having an "Integrated Database" I suppose; i.e. the database is an integral part of the OS, so consequentially a number of OS commands will provide an [possibly very direct] interface to the database activity. Other databases might be an add-on to the OS and consequentially the capability for OS commands to impact the non-OS database files could be generally undesirable.

Ignoring the origins for the capability, consider that a database file with the attribute of RUSEDLT(*YES) to enable reuse of deleted records can take advantage of a feature to improve insert performance; i.e. concurrent insert, which I believe was even noted in a recent thread about extents which also is relevant to insert performance.

As for being able to add deleted records, because an inserted deleted rows does not populate the file as\with an "active record", they are generally innocuous with regard to impact on business rules; i.e. as alluded, no impact on triggers, constraints, applications waiting-on new rows or reading either by key or sequentially, etc. Then because a deleted row can be positioned-to like any other record when employing "direct" positioning requests, as with OVRDBF POSITION(*RRN &rrn), an update to that record makes that row\RRN become an active\undeleted record. That capability allows data copy from an active row to a previously deleted row, as implementation for reorganizing to compress deleted rows [from the lower RRN of the dataspace to the end, such that the database can eventually be truncated of only since-deleted RRNs].

A very important aspect for the capability is the value for a deleted row to mimic effects of journaled operations which might need to insert a row RRN-78 but for which presently, the last RRN=70. Understanding that concurrent activity with isolation can give rise to and thus make sense of that seemingly illogical scenario.

The I\O feature for adding deleted records is the program QDBPUTD. A search of the web for that program name will reveal HA references; i.e.
mimic journal apply activity to synchronize data.

Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.