AS/400: exceeding 9999 records in load all subfile?

165 pts.
Tags:
AS/400 Subfiles
My question : I am using a load all subfile.Now when the records exceed 9999 records,(for example the page i am visting is the 9999th record page),what will happen if i press page-up. And will the subfile give error if i load this file with 9999+ records ?

How to handle the page-up & down in this case of load-all?



Software/Hardware used:
AS400
1

Answer Wiki

Thanks. We'll let you know when a new response is added.

I always just put 1500 in that field. My theory is a user is not going to scroll down and look at all those records. So put a search in the subfile for 2 reasons. Faster response and user friendly..
Ron

Discuss This Question: 16  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • ReshmaG
    Hi First thing is that u can't load more than 9999 at a time at all. and this is the limitation in Load all subfile If u need to do that u need to use Single page Subfile where u need to handle Page Up and Pagedown. Please check out the link for the Subfiles http://osdir.com/ml/lang.as400.rpg/2002-11/msg00196.html Regards Reshma
    455 pointsBadges:
    report
  • Supriyob2
    I know the constraint...but my quetion was: what will happen if there are 9999+ records in a PF and i am using that file in load-all SFL. will it only show till 9999 or after that it will abend?
    165 pointsBadges:
    report
  • ReshmaG
    No matter how many records are there in a PF but for load all u can load only 9999 max.. i.e. in the Subfile u need to mention SFLSIZ = " Number of records u want to load " it will load at a time 9999 only u can'tgive more than 9999
    455 pointsBadges:
    report
  • DLM2007
    Recompile the the physical file's initial records to *NOMAX. The default is 10,000
    295 pointsBadges:
    report
  • Teandy
    I believe that the program will abend when loading the subfile and I know for certain that the program will abend if you try to page down past the 9999th record. If I were doing this, I would use either a page at a time subfile or a load all that holds between 1500 to 2500 records. Both would have a search field to set where the subfile starts to read the PF.
    5,860 pointsBadges:
    report
  • Littlepd
    Assuming you've coded your program to catch the error you are going to receive when you try to write record # 10,000 to your subfile then continue on to display the subfile, you will get a warning message on the screen when you reach the end of the subfile. You will not be able to scroll past that last page. As for how to handle the page keys in this case, you can't. Load-all subfile don't let you handle page keys, they handle them for you. Control is never returned to your program for you to even know that a page key was pressed. If you want to have a subfile that displays that many records from your file, it cannot be a load-all subfile. You must make it a page-at-a-time subfile. That means handling all of the page keys that are pressed, not just the last one, and you must load each page every time a page key is pressed.
    1,130 pointsBadges:
    report
  • Vatchy
    If you expect that a user will need to scroll through more than 9999 records then you need to use a SFLSIZ = SFLPAG+1 subfile and include a position-to field in the display file so that the user can do instant positioning rather than having to scroll that many pages. Also, loading 9999 records before showing the subfile to the user will cause a significant delay.
    1,415 pointsBadges:
    report
  • TomLiotta
    Minor correction -- it would be a SFLSIZ = SFLPAG subfile, a page-at-a-time subfile where the size is defined equal to a single page. For the question, the number of records in a PF is not related to the number of records in a subfile. A subfile will only hold what you successfully write to it. You can try to write more than 9999 rows to a subfile, but the next write won't succeed. I think it will result in a simple error with status 00013. (It's probably been 20 years since I've seen any attempt to write that many rows. There is no point to having 500+ pages to scroll through in a subfile.) Tom
    125,585 pointsBadges:
    report
  • Vatchy
    The important point in my post was the "position-to" information. That is useful to allow the user to avoid having to scroll through 9999 records. Just use the position-to info to SETLL and start the subfile from there.
    1,415 pointsBadges:
    report
  • TheRPGcoder
    My question is this... I have a PF with 9000 records and I have created a load all subfile which can display 5000 records. What will happen if i press page down when the 5000th record is displayed in the subfile?
    Also as Subfile size basically determines the amount of data that can be stored in subfile.. can we show all 9000 records on this file?
    10 pointsBadges:
    report
  • TheRealRaven
    Subfiles aren't declared to hold only 5000 records. For a load-all subfile, you can always write as many as 9999 rows to it. SFLSIZ determines how much memory is allocated when the subfile is opened, not how many rows can be put into it. With SFLSIZ=5000, the 5001st row causes additional memory allocation. Other than that, nothing visible will happen until you try to write row 10000.

    You should set SFLSIZ to represent how many rows you often expect to exist. It's a minor performance element. In earlier years, it could be important to control memory more closely.
    33,220 pointsBadges:
    report
  • azohawk

    Personally, I would not normally use a load all if the there will be more than a handfull of records. Users will get tired of the scrolling required to advance through the screens to find what they are looking for. In this situation, I would use page at a time with a position to on the screen.

    Not sure what the data is in the PF, but what if it grows beyound 10,000? You will not be able to load (without reloading) the remaining records. If the user has scrolled through that many records, do they really want to wait for more to load?

    4,015 pointsBadges:
    report
  • TheRealRaven
    It's probably best to focus on page-at-a-time subfiles. Learn those, and everything else about subfiles becomes easier. Further, you can make a pattern and use it forever into the future.

    It can often seem that learning load-all will solve most problems in the beginning, but it really just makes the whole learning process more complicated. Page-at-a-time can be used for every possible subfile, but both load-all and expanding subfiles have restrictions that limit their applicability.

    If you already know page-at-a-time, it's far easier to do a load-all when later circumstances make one of them useful.
    33,220 pointsBadges:
    report
  • GregManzo
    Arg! No! Avoid as much as possible page-at-a-time unless there is a solid technical reason requiring it (like conditional fields that cant be handled with DSPATR). And NEVER use a load-all subfile - use an extending subfile. You load a single page and specify PAGEUP/DOWN in your DDS so you can extent the subfile as necessary. Keep your key fields as hidden fields in the subfile so that you can always re-position to where you are now if the user presses F5=Refresh. If they page within the existing subfile DDS will handle it, if they page beyond the end you read the last subfile record to get your hidden keys and extend by one more page, if they scroll back before the first record you clear the subfile and build one page backwards from that key. If you ever have a user dumb enough to scroll for 9999 records you (a) tell the wanker to change hands, or (b) clear your subfile if RRN > 9900 and build a single page. And put a position-to field just above the main sort key, so the users can position directly into the file if they have a vague idea of what they are looking for. This standard has allowed us to provide effectively infinite scrolling into a file with 180,000+ records, and the standard is enforce by putting ALL the subfile load & scroll logic in /COPY members making it much easier to to do it right than try to do it yourself and get it wrong. There is no limitation, 500+ subfile screens later & they are all handled by this /COPY. We typically use SFLSIZ=SFLPAG+1.
    NB: SFLPAG = number of records shown on screen, SFLSIZ = number of records allocated memory at open, if you go beyond this more memory is allocated dynamically. If you try to write > 9999 records to a subfile the write will fail. Number of records in the PF is completely irrelevant.
    2,925 pointsBadges:
    report
  • TheRealRaven
    As long as it's a site standard, I'd easily accept expanding subfiles. And definitely agree with both the use of /COPY for the logic regardless of type and hidden fields for key storage.

    Though the DDS for expanding subfiles can help with paging up/down, code is still required to handle it; so no relief comes to the developers. That code becomes closer to 'exception' procs and is less familiar.

    But when done well, program code for expanding is essentially the same as for page-at-a-time. A couple differences come in the DDS and the expanding's check for ">9999".

    For new developers, I'd go to page-at-a-time until some confidence appears. Then personal choice to use expanding is clear.
    33,220 pointsBadges:
    report
  • GregManzo
    All the code to handle paging is in the /COPY, in fact the entire mainline logic for every work-with is in the /COPY (2600+ lines of code). Developers only need to populate a few subroutines that get called by the copy for things like fetching a product description. Plus nominate the key fields on two standard KList's, and specify a few conditional /DEFINE's to handle variants like filling the last half page with empty records for input.
    Yes, the code is essentially the same - I'd suspect probably exactly the same except for the SFLSIZ keyword and the requirement to clear the subfile before every page. This is why I'd rather keep what I've already built and add to it, just to save a few I/Os.
    But I'm still a little envious - where are you finding new developers for RPG? I thought the new guys were all learning C and Java.
    2,925 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.

Following

Share this item with your network: