RE: impact of deleted records

Thanks to all who have contributed.

I'm well aware of the REUSEDLT keyword. In fact this huge file does appear to have REUSEDLT(*YES).
Populating it has not been well thought out since the process appears to end up deleting far more records than it adds, and it's journalled for mirroring to boot.
Reorganizing it is now obviously an issue. I believe it is accessed primarily via embedded SQL with the appropriate access paths so I expect that data management can provide efficient access.
But I was wondering if maintenance during business as usual can suffer because of the need to find deleted records for reuse.

Peter


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jon Paris
Sent: Tuesday, 1 July 2014 2:33 a.m.
To: Midrange Systems Technical Discussion
Subject: Re: impact of deleted records

Simple answer - yes. But why would you force it to?


On 2014-06-29, at 5:34 PM, Peter Connell <Peter.Connell@xxxxxxxxxx> wrote:

Huge file of 74 million rcds has 301 million deleted records and several logical files.
Can data management really handle this with little performance impact if there are regular additions/deletions?


######################################################################
###############

This correspondence is for the named person's use only. It may contain
confidential or legally privileged information, or both. No
confidentiality or privilege is waived or lost by any mistransmission.
If you receive this correspondence in error, please immediately delete
it from your system and notify the sender. You must not disclose, copy or rely on any part of this correspondence if you are not the intended recipient.
Any views expressed in this message are those of the individual
sender, except where the sender expressly, and with authority, states them to be the views of Veda.
If you need assistance, please contact Veda on either :- Australia
customerassistance@xxxxxxxxxxx or New Zealand +64 9 367 6200
--
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.

Jon Paris

www.partner400.com
www.SystemiDeveloper.com




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

#####################################################################################

This correspondence is for the named person's use only. It may contain confidential
or legally privileged information, or both. No confidentiality or privilege is waived
or lost by any mistransmission. If you receive this correspondence in error, please
immediately delete it from your system and notify the sender. You must not disclose,
copy or rely on any part of this correspondence if you are not the intended recipient.
Any views expressed in this message are those of the individual sender, except where
the sender expressly, and with authority, states them to be the views of Veda.
If you need assistance, please contact Veda on either :-
Australia customerassistance@xxxxxxxxxxx or New Zealand +64 9 367 6200