|
OK, if that's the case I should be able to use my current applications with very little change. Just set the MODS to 32767 in the D-specs, Reallocate it to one occurrance as soon as I initialize, since I only need one for keys and such. Then, when the I/O routine returns with 147 records and a pointer, Reallocate my MODS to 147 and set it's basing pointer to the pointer returned from the I/O module. Cool. Thanks. > -----Original Message----- > From: MWalter@hanoverwire.com [SMTP:MWalter@hanoverwire.com] > Sent: Wednesday, April 10, 2002 3:55 PM > To: rpg400-l@midrange.com > Subject: RE: Separation of Presentation, BL, and I/O Tiers > > > Nelson, > > I believe that if you define a MODS or ARRAY as BASED, No storage is used > until you allocate the number of bytes required to the pointer. The only > thing that gets me is that if you define an array as based and dimension > it > to 32767 elements, if you only allocate enough memory for 10 elements the > %elem BIF still returns 32767. I wish there were a way to determine how > many actual elements were allocated. Because of the memory allocation > blocking, you couldn't get exact but you could get close. > > Just my 2 cents, > > > Mark > > > Mark Walter > Sr. Programmer/Analyst > Hanover Wire Cloth a div of CCX, Inc. > mwalter@hanoverwire.com > http://www.hanoverwire.com > 717.637.3795 Ext.3040 > > > > "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.
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.