|
midrange.com
To append my last message, the record that is retreived from my @RTV
procedure is an exportable data structure.
So, code is very minimal.
David L. Mosley, Jr.
Systems Analyst
2000 CentreGreen Way
Suite 250
Cary, NC 27513
dmosley@dancik.co
m To: rpg400-l@midrange.com
Sent by: cc:
rpg400-l-admin@mi Subject: RE: Separation of
Presentation, BL, and I/O Tiers
drange.com
04/10/02 03:34 PM
Please respond to
rpg400-l
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.
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.
