|
Comments in line "James W. Kilgore" wrote: > You have the basics down, but I would do two things differently. > > Not that your code is wrong, but, > > 1) I have found that using UP to process a file can create a problem. Since > every record gets locked, update or not, you can fall into a lock wait. By >using > the file twice, once as IP then again as UF you gain blocking and only lock >the > records that need an update. If the file being processed does not have a >unique > key, get the record to update by record number which can be given to you from >the > file feedback data structure. Interesting... I wouldn't need to do that in this program, as this is a transmission file and is being used exclusively, and my production files are all keyed so I normally do a CHAIN, which means it is a UF usually, and I only read the records I am actually wanting to change. Our primary file is almost always Input only. But this is a good idea and I will keep it in mind. > 2) Using the UPDAT command is more overhead than you really need. Again >there is > nothing wrong with UPDAT, but we prefer an EXCPT with only the fields that are > being changed listed. (Besides it makes it very clear as to which field >values > the program affects. Actually, I find UPDATE much easier to understand myself, from a self documenting point of view. If I come across a program that is changing fields, then does an UPDATE I know what it is doing. But, when I come across a program that has an EXCEPT to out output spec, I have to jump down and see what is being updated. There may be some additional overhead it writing the record, but I don't think that could be anything significant to a program. Regards, Jim Langston +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.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.