× 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.


  • Subject: RE: Sub files in RPGLE
  • From: Paul King <Paul@xxxxxxxxxxxxxx>
  • Date: Wed, 21 Oct 1998 21:35:53 +0000

Martin,
        I would strongly recommend investing the time in writing one simple
and well strucured 'template' program that works page at a time. Thereafter
you simply copy and change the field names to suit, DDS first then your RPG.
If you define your DDS to have the same field names as that of the file you
are loading from then is it even easier (some people don't like doing it
this way, I can't see why as for most pgm's it makes perfect sence. Bucks
later example assumes this as per

     dow
     read  txt
     write sflrec
     enddo
.
                        )


Paul

At 10:02 19/10/98 -0400, you wrote:
>On Monday, October 19, 1998 1:59 AM, Easwar [SMTP:easwar@md3.vsnl.net.in] 
>wrote:
>> I have a question on ILE RPG. The qestion relates to subfile. In the
>> condition where SFLSIZ = SFLPAG + 1, the system takes care of the Page
>> Up and Page Down key. Is this particular for ILE ?.  And When I give a
>> Page Down key after the last page is displayed, It shows a blank page
>> and then the Page Up doesnt work properly. I am using Relative record no
>> to navigate through the subfile records. I can give the source file if
>> needed. Could someone give me a hint in this? A working RPGLE code would
>> be fine.I am working on 9401 and V3R7.
>
>Easwar,
>  When SFLSIZ<>SFLPAG, the system does not automatically take care of page 
>up/down unless the user is paging within the limits of the subfile records 
>already loaded.  If the user tries to page beyond the records already 
>loaded, your program gets control, with the PAGExx indicator set on.  At 
>that point, it is up to your program to determine what to do.
>
>Many times, people will load a single page of the subfile at a time, to 
>minimise the performance issues associated with loading all the records at 
>once.  A simple example may serve to enlighten:
>
>Imagine that your application is going to display all the long distance 
>telephone calls for a single telephone number.  Any one customer can have 
>as few as zero and no limit for the maximum number (imagine the phone bill 
>of a large corporation with thousands of employees.)
>
>Scenario 1
>
>SFLSIZ<>SFLPAG
>Page Up/Down not specified
>If you load all 5000 records into the subfile at once you will be doing 
>one read/write for every long distance call that was made.  But what if 
>the user looks at the calls on the first page and realises that they are 
>looking at the wrong customer?  Then we have spent all that time loading 
>thousands of records into the subfile and the user never looked at them 
>all.
>
>Scenario 2
>
>SFLSIZ<>SFLPAG
>Page Down specified
>If you load one page of records into the subfile at a time, the user will 
>only have to wait for one page to load, but because SFLSIZ<>SFLPAG, OS400 
>will handle the paging between those pages that are already loaded, and 
>your program will not get control until the user pages past the end. 
> Then, your program gets control and you can load another page, and 
>essentially "expand" the records by one page at a time, something like 
>this:
>
>         DoW *In03=*Off
>         Exfmt SFLCTL
>         If *In03=*Off
>         If "pagedown indicator"=*On
>         ExSr LoadPage
>         EndIf
>         EndIf
>         EndDo
>
>LoadPage BegSr
>         Eval  CurrentRRN=HighestRRN
>         Eval  EOF=*Off
>         Eval  RecsThisPage=0
>         DoW   EOF=*Off
>Telnbr   Reade LongDist
>         If    %eof
>         Eval  EOF=*On
>         Else
>         Eval  CurrentRRN=CurrentRRN+1
>         Write SflRec
>         EndIf
>         EndDo
>         Eval  HighestRRN=CurrentRRN
>
>Check the manual Application Display Programming, SC41-4715 for more 
>details.
>Also, feel free to check out http:www.midrange.com  Follow the links to 
>books (this is amazon.com).  Any books you buy there help fund this mail 
>list.
>
>hth,
>Buck Calabro
>Commsoft, Albany, NY
>mailto:mcalabro@commsoft.net
>
>* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>* This is the RPG/400 Discussion Mailing List!  To submit a new         *
>* message, send your mail to "RPG400-L@midrange.com".  To unsubscribe   *
>* from this list send email to MAJORDOMO@midrange.com and specify       *
>* 'unsubscribe RPG400-L' in the body of your message.  Questions should *
>* be directed to the list owner / operator: david@midrange.com          *
>* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>
>

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the RPG/400 Discussion Mailing List!  To submit a new         *
* message, send your mail to "RPG400-L@midrange.com".  To unsubscribe   *
* from this list send email to MAJORDOMO@midrange.com and specify       *
* 'unsubscribe RPG400-L' in the body of your message.  Questions should *
* be directed to the list owner / operator: david@midrange.com          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.