× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



if you're really brave you could use DSM APIs...

Thanks,
Tommy Holden




"Takken, Cor" <cor.takken@xxxxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
05/15/2007 08:23 AM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
"RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
cc

Subject
RE: today's how-best-to question...






Bryan,

In your posting you refer to the "file like" source and to the user
space source coming out of the API. Where in fact the function which is
building/composing the subfile should not care, here you scratch the
surface of design issues. Why should a subfile building method care
about the actual source of the information. A much cleaner approach to
this matter should be that the page by page subfile filling method
should request the information line by line by another function which
has the knowledge as to how to retrieve the next piece of information
(either from file, from API or well.. what sources can you think up?).
The whole program should be carefully thought out, and in the end you
will probably end up with a construction which is not so much different
from the way it is done in UIM.

IMHO page by page is simpeler (i.e. more commonplace), but UIM is much
more flexible. It depends on your knowledge basically.

Just my two cents.

Cor Takken

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Bryan Dietz
Sent: dinsdag 15 mei 2007 14:57
To: RPG programming on the AS400 / iSeries
Subject: today's how-best-to question...

I have a how-best-to question:

I have a utility program that gets a list of objects using
the QUSLOBJ API then retrieves info about each object in the
list and displays in a subfile.

The problem I ran into is that if the list has more than 9999
records it
blows up the subfile.

As I see it I have two choices; "page at a time" subfile or a
UIM panel.

I know that a UIM panel would not have the 9999 record
limitation and I have used them.

I can see that a "page at a time" subfile works well for data
from a file, or "file like" source. I am struggling to
figure out how best do the same with the list api data in the
user space.

I am thinking of cranking thru the list api and building a
temp dtaq or file to store the data then read from there to
populate the "page at a time" subfile. I worry about the
performance having to essentially read the data twice to show
the first page.

I am not inclined to use the initial user space as I would
have to keep retrieving the object info for each page up/down request.

Bryan
--
--
This is the RPG programming on the AS400 / iSeries (RPG400-L)
mailing list To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.




This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege. It should not be copied,
disclosed to, retained or used by, any other party. If you are not an
intended recipient then please promptly delete this e-mail and any
attachment and all copies and inform the sender. Thank you.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.