|
Aaron, We did this originally for just the reason you outlined. Our experience was the effort we saved with the degree of separation (recompiles) was adding to the effort necessary to implement and maintain the code. I think that if we had a CASE level tool that would not be the issue. We also don't have to deal with distributing our code to external customers Note: We are definitely using our in-house code generating tool. Not sure I can send the code out though :0( I would recommend that you do write your own, pays for itself. >>> ALBartell@taylorcorp.com 04/12/02 08:25AM >>> But now you don't have the same degree of separation because I am guessing you define an external data structure in the programs that use the getState() and setState() modules. If you keep it at a field level like so eval custName = getCustName() then you don't have to recompile every program that uses the customer file when the customer name gets expanded by 30 bytes, just the ones that actually use customer name. In my situation changing the customer master file requires quite the work and since we have to distribute our software to about 20 companies the chance for level checks is much much higher. Aaron Bartell -----Original Message----- From: Andrew Lutz [mailto:alutz@pmigroup.com] Sent: Friday, April 12, 2002 9:56 AM To: rpg400-l@midrange.com Subject: RE: Separation of Presentation, BL, and I/O Tiers Aaron, I have implemented this setter/getter for every field methodology in a previous project. Yes, we generated the programs automatically. But eventually you must maintain them outside the generator. Lot of work. Not to mention a lot of procedures, that made Large programs. This time we are implementing a getState() setState() style approach where the entire object structure is passed. Much simpler. Easier to maintain. Smaller programs. >>> ALBartell@taylorcorp.com 04/12/02 06:32AM >>> We are trying something new in our software where we are doing something similar to what is being talked about here. We are creating IO modules for all of our files. Here's what I am wondering. Since every service program will be the same except for the names of the subprocedures we are thinking about writing a program to produce the getter and setter methods for each field, similar to how some Java IDE's do it for you based on the variables you define in the object. We wouldn't be writing a program to do this if there wasn't a gazillion files that we had in our software, but each one needs to have a service program created for it. Has anybody done this before, and if you have would you be willing to share the code that it took to dynamically write the programs? Thanks in advance, Aaron Bartell -----Original Message----- From: dmosley@dancik.com [mailto:dmosley@dancik.com] Sent: Wednesday, April 10, 2002 2:35 PM To: rpg400-l@midrange.com Subject: RE: Separation of Presentation, BL, and I/O Tiers I curious about the use of MODS (and thank you Aaron for asking the meaning). Is the use of MODS easier than using single record retrieval. Reason I'm asking, is becuase I've created a very basic service program with two primary procedures. @SETLL, and @RTV. The @SETLL dynamicaly builds the Select statement based on passed position-values, and prepares the statement. Then I would do a DO-loop around my @RTV and retrieve each individual record as they are FETCHed. The @RTV would pass back an error-indicator. This indicator would specify either EndOfFile, or Error-Occurred during the FETCH. Anyway, I've been using this type of retrieval for a while, and never really thought about using MODS. Does using MODS enhance the performance of the FETCH any? Thanks dav David L. Mosley, Jr. Systems Analyst 2000 CentreGreen Way Suite 250 Cary, NC 27513 "Smith, Nelson" <NSmith@lincare.c To: "'rpg400-l@midrange.com'" <rpg400-l@midrange.com> om> cc: Sent by: Subject: RE: Separation of Presentation, BL, and I/O Tiers rpg400-l-admin@mi drange.com 04/10/02 03:23 PM Please respond to rpg400-l If you have to define it at the maximum occurs, what does being dynamic buy you? Would you immediately go in at program startup and resize it back down to a reasonable number? Would that be the benefit? You say "as for an array". I thought I had seen examples of people starting off with a 100 element array and then resizing it to 200? You can't do that? The end result I'd like to get to is to have an I/O routine that gets a bunch of records (by RPG, SQL, Stored procedure, whatever), sizes an array or ds to hold them based on the number it found, then just return a pointer to the structure along with the number of records contained in it. So, would the I/O module have to declare the MODS at the maximum Occurs, get the records, then reallocate the MODS back down to the actual number of records retrieved, then return to the calling program? Then, the calling program would have to do the same thing, start off with a maximum size ds, and reallocate it down after it got the pointer back from the I/O module? Is that the scenario? Would there be any performance issues here, when an application may be doing this for hundreds of files? > -----Original Message----- > From: Jon Paris [SMTP:Jon.Paris@Partner400.com] > Sent: Wednesday, April 10, 2002 2:51 PM > To: rpg400-l@midrange.com > Subject: Separation of Presentation, BL, and I/O Tiers > > >> I've seen several posters saying they could, but have seen no examples > of that, yet. > > MODS can be based (and therefore dynamically sized) just as arrays can. > The > limitation (as for an array) is that you must define the number of > occurrences as the largest number you will ever need. I like the > technique > because it has the added advantage that you can have multiple definitions > of > the DS and map them to individual occurrences of the MODS so you simply > directly compare multiple occurrences. > > You can also use things like the C qsort and bsearch routines to sort and > search the MODS. > > Jon Paris > Partner400 > > > _______________________________________________ > This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list > To post a message email: RPG400-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l > or email: RPG400-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/rpg400-l. **************************************************************************** **************************************************************************** **************************************************** This message originates from Lincare Holdings Inc. It contains information which maybe confidential or privileged and is intended only for the individual or entity named above. It is prohibited for anyone else to disclose, copy, distribute or use the contents of this message. All personal messages express views solely of the sender, which are not to be attributed to Lincare Holdings Inc., and may not be copied or distributed without this disclaimer. If you received this message in error, please notify us immediately at MailAdmin@lincare.com or (800) 284-2006. **************************************************************************** **************************************************************************** **************************************************** _______________________________________________ This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l or email: RPG400-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l. _______________________________________________ This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l or email: RPG400-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l. _______________________________________________ This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l or email: RPG400-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l. _______________________________________________ This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l or email: RPG400-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l. _______________________________________________ This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l or email: RPG400-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-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
