reusedlt *yes
Backup & recovery, Data center operations, Data mining/analysis, Data warehousing applications, Database Management Systems, DB2, DB2 administration, DB2 Implementation, Disaster Recovery, Hardware, Help Desk, i5, IBM, iSeries, OS/400, Performance/Tuning, Security management, Software Quality Assurance, System monitoring, Tech support, tips and tricks, Tools
Hi,
Has reusedlt *yes behavior changed with V5R3?
When I add a record to a PF that is reusedlt *yes in V5R2 is uses a record that has been deleted, however when i do the same thing on a V5R3 system it adds a new record rather than re-use one.
Anyone run into this before?
Thanks,
Luis
Software/Hardware used:
Software/Hardware used:
ASKED:
May 23, 2005 2:52 PM
UPDATED:
November 1, 2011 9:56 PM
RELATED QUESTIONS
- How to determine if ANY fields have changed in a file, when user maintains a record of info
- what is the query to be used in openquery file to read records in reverse from a database file
- Sending a break message to more than just one message queue
- Can wrkrmtwtr command be used on V6R1?
- Prompting for and passing partial search criteria to queries
Answer Wiki:
V5R3 PTF MF34478 has something to do with reuse of deleted records. Actually, PTF MF34836 is the latest supercede PTF. It has a lot of co-reqs, so I would install the latest HIPER PTF package (SF99529)along with the Database group package (SF99503)and of course, the Cumulative PTF Package of SF99530.
Good luck!
To see all answers submitted to the Answer Wiki: View Answer History.
Do you have to recompile your file if you change this parameter to *yes?
Do you have to recompile your file if you change this parameter to *yes?
In general, no.
The reason to recompile is usually that the I/O buffer layout has changed. That might be because a field length or data type was changed or fields were added or removed which caused other fields to be in different locations in the buffer.
Changing the REUSEDLT() attribute doesn’t cause any differences in the buffer layout, so nearly all programs still see the same record image as before.
An exception would be a program that actually relied upon the physical sequence of records in the file. Processing sequentially by “arrival sequence” means that records come into the program beginning physically with record #1 and continuing with each higher record number.
Reusing deleted record space allows DB2 to put new records into spaces where records have been deleted rather than simply always appending them to the end of the file. That would require changes to the logic of such a program and necessarily lead to a recompile.
Nowadays, that kind of logic should be very rare. A timestamp field or other key field should be in control of the sequence. Or a program simply won’t care if record #10 happened to be added physically after record #100.
Nevertheless, such logic does need to be watched for, particularly in older applications or even in large products.
Tom