|
I don't have the luxury of using embedded SQL since we don't have SQL DevKit. So, I must use native RPG I/O in my encapsulation endeavors. What should I do to prevent record-locking ? Should I code every operation no-update (N) and read the record for update when I need to ? Or, do I need to not worry about record locks and be more concerned about whether the record was updated by another user since the last read ? -----Original Message----- From: Joel Cochran [mailto:jrc@xxxxxxxxxx] Sent: Thursday, September 02, 2004 9:10 AM To: RPGNext Discussion and Information Subject: Re: [RPGNext] Encapsulating file access in Service Programs On Thu, 2004-09-02 at 14:23, Richard Rothe wrote: > I am beginning to encapsulate file access in a "Service Orirtented > Architecuture" as described in a previous post by Aaron Bartell. It > is working very well. Encapsulation has become one of my favorite designs, I use it extensively. > What is the preferred method of providing a return code of the file > operation to the calling program ? Should I provide a return code on > every procedure that I write ? For functions that don't return a specific value (like a getter), I tend to return a "successful/not-successful" indicator. Like Aaron mentioned, this makes sematntic use of the code very easy. About the only time I don't include a return code at all is on a lot of the setters, because the prototyping handles the basic error checking. If I need something specific, say a verification, then I will include an indicatored response. An advanced technique of my Encapsulation service programs is to include a "retrieveLastError" procedure, so if something like this fails I can recover a message at will (pull rather than push). > Or, just provide a procedure to determine the status separately ? > Like PartIsFound for determining if a part is in the Item Master. Again, this is the semantic use of procedure names and is, IMHO, the only way to go. The beauty is that I can use this procedure internally, say in a setter proc, or externally from another program. > Also, I've seen where others have standardized on always passing data > back using the Procudure interface and never parameters claiming that > the parameters should only be used for input to the procedure. If > multiple fields need to be returned, a data structure is used. I've actually standardized in the opposite direction. I very rarely use anything but CONST for my procedure parameters. I don't want unexpected changes to the parameters in my calling programs. I only have one procedure that passes back multiple parameters, and I do that by using the return value for the main one and a pointer for the second, so the parameters are still all "pass-in" only. If you do pass DSes back and forth, put them in a /copy so they are the same. Joel http://www.rpgnext.com _______________________________________________ This is the RPGNext Discussion and Information (RPGNext) mailing list To post a message email: RPGNext@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/rpgnext or email: RPGNext-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/rpgnext.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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
