|
>How does DBU's product "RDR" accomplish this task? In brief-- When a record is deleted from a file, as long as the file is NOT reusing deleted records, and until the next reorganize of the file (RGZPFM), the record is NOT really gone! It's just been flagged for deletion. When you use RGZPFM, the live records are all squeezed down to one end of the file, and the deleted records are at the other, and available for (re)use. When you save/restore a PF, all of the records go along for the ride. Including the ones flagged for deletion. What these programs do is save the file to a save file. A save file can be read in an RPG program. "Simply" read the save file, and copy the resulting data to a new file with the same attributes of the original. The deleted records are flagged as deleted, the live records are not. The tricky part is that the record length of the save file (RECL 528, IIRC), will probably NOT be the record length of your file! Plus, the save file has some additional bytes sprinkled here and there (notably the live/deleted flag; there may be others). You'll have to buffer the input file and re-assemble the pieces of your records. [Some of your records will span more than 1 record in the save file] That's the key. I haven't tried DBU's method with a real file; Does it need equal space to the original? What happens if it's a HUGE file?? I don't know if there's another way to get at the data other than thru a save file. Is there an API? I haven't checked. --Paul E Musselman PaulMmn@ix.netcom.nospam.com
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.