|
REUSEDLT(*NO), the default, should go to the end of the file. Al Al Barsa, Jr. Barsa Consulting Group, LLC 400>390 "i" comes before "p", "x" and "z" e gads Our system's had more names than Elizabeth Taylor! 914-251-1234 914-251-9406 fax http://www.barsaconsulting.com http://www.taatool.com http://www.as400connection.com Jerry Adams <jerry@bwwholesal e.com> To Sent by: Midrange Systems Technical midrange-l-bounce Discussion s@xxxxxxxxxxxx <midrange-l@xxxxxxxxxxxx> cc 07/31/2006 05:41 Subject PM Re: REUSEDLT *NO and INSERTS Please respond to Midrange Systems Technical Discussion <midrange-l@midra nge.com> Makes sense, Al, but I thought he said REUSEDLT(*NO). In that case, I would, also, have expected the records to be added at the end of the file. To ascertain if the records are really added at the end (or not), wouldn't it be possible to issue an OVRDBF specifying a starting position based on *RRN, then run DSPPFM and go to the bottom of the file. I.e., if the file had 1-n deleted records, and one record was added to a file with REUSEDLT(*No), wouldn't that (added) record be the last record in such a list? For a REUSEDLT(*Yes) file, it could be anywhere (relatively speaking). Right? * Jerry C. Adams *IBM System i Programmer/Analyst B&W Wholesale Distributors, Inc.* * voice 615.995.7024 fax 615.995.1201 email jerry@xxxxxxxxxxxxxxx <mailto:jerry@xxxxxxxxxxxxxxx> Al Barsa wrote:
When you open a file specified as REUSEDLT(*YES), is creates a "deleted record map" for the file, and inserts them in the deleted spots. A second open of the file for add will get it's own map. i.e.: If someone else deleted a record while you have it open, your job won't see that deleted record. Al Al Barsa, Jr. Barsa Consulting Group, LLC 400>390 "i" comes before "p", "x" and "z" e gads Our system's had more names than Elizabeth Taylor! 914-251-1234 914-251-9406 fax http://www.barsaconsulting.com http://www.taatool.com http://www.as400connection.com
"Ryan Hunt"
<ryan.hunt@highwo
ods.com> To
Sent by: midrange-l@xxxxxxxxxxxx
midrange-l-bounce cc
s@xxxxxxxxxxxx
Subject
REUSEDLT *NO and INSERTS
07/31/2006 03:07
PM
Please respond to
Midrange Systems
Technical
Discussion
<midrange-l@midra
nge.com>
Question about a file with REUSEDLT *NO. I figured this would be the best REUSE setting for a file that receives large bulk inserts. Essentially,
we
end up deleting as much as 10% of the file and then INSERT a slew of updated records as one batch. I assumed this would place the records at the end
of
the file - which would be easiest and quickest. Howerver, when viewing
the
QZDASOINIT job running the insert and selecting option 14 and then hitting F11, there is a display for "Relative Record" - which I assume is the current ordinal record position currently locked by the INSERT. Well, the relative record number is jumping all over the place within the file while I'm expecting to see an incrementally increasing relative
record
number (previous maximum ordinal plus 1) since I'm expecting records to be inserted at the end of the file. Something else I was considering is maybe I am seeing the relative record number of the unique index over the table - verifying the constraint
before
each insert. Maybe each insert is seeking on the unique constraint and I just happen to see the ordinal position of the seek at the exact moment I hit F11? Anyway, can anyone add some color to the "relative record" display on the Display Open File screen...as well as confirm that REUSEDLT *NO is the fastest insert option. Thanks Ryan -- 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 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.
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
