Generating a Report on AS400

Is there any good way to determine the number of pages a report will print without actually generating it first? I would like to have my report print as part of it's headings : Page 1 of 50, Page 2 of 50 etc.

Answer Wiki

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

The simple answer is no. The total number of pages can only be determined by running through the output twice. In the past I have handled this issue by writing the detail lines out to a workfile, counting the number of detail lines (as each is output) and then generating the spooled document directly from the workfile entries (after determining the total number of required pages based on the number of detail lines per page). There may be an alternate way to handle this dilemma but this is the only method I have encountered in numerous IT shops.


Only way I know to be certain is to generate the report first. Place some recognizable constant in the positions occupied by page numbers while generating the report. Once the report has been spooled, retrieve it into user spaces, process the spaces to place your TotalPages value into everywhere you have page numbering tagged and then re-spool from the user spaces.

You won’t need a constant or marker if you feel confident enough to locate the positions by interpreting the space text.


Discuss This Question: 3  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.
  • WaltZ400
    If you are printing your report from a work file that contains everything that will print on the report, in RPG in the INFDS for a file in positions 156 thru 159 you will get the record count of that file when the file is opened in the program. If you are strictly writing a detail only report, you should be able to figure out how many detail lines you would have per page and divide that into the record count and round up to get total pages. If you are doing summary total prints within the report this could be a little tricky as you couldn't judge just by a record count how many extra blank lines might appear on a page between totals etc.
    655 pointsBadges:
  • Acjitk
    You can also do the following. It is a bit of work but you never have to worry how future changes to the report will impact your page counting: 1) Write the report with the heading "Page #### of ____" where #### is the actual page number (ex. 1st page will print "Page 1 of ____"). 2) Use the command CPYSPLF to copy the report to a physical file. Use the option in the command that writes out the first 4 bytes with line number information (I forgot what it is) 3) Write a program that reads this physical file backwards starting with the end of the file. Find the column where the Page Number is located and stop reading the first time this is found. You now have the total pages. 4) In this same program, start from the beginning of the file and replace the columns containing "____" with the actual total page number. 5) Write a program that reads the updated physical file and writes out each record to a report making use of the line skipping information in the first 4 bytes of the file. This program is reusable for any time you want to print from a file created by the CPYSPLF command. I have used this approach once. It is a lot of work but it does work and it is mostly reusable if other report headings are kept standard.
    0 pointsBadges:
  • Cpinhey1
    When populating a workfile that is being used to generate a report I generally do not output heading or summary line information to that workfile. I usually define the workfile in my F-SPECS as being user controlled; I clear the workfile within the RPG/RPGLE initialization routine and I only OPEN the file if I have at least 1 detail line to output. I then count each detail record as it is written - if my count is zero then the workfile was never opened. Once I have completed loading the file, I position my pointer back at the first entry and process sequentially through the records. Using this approach I am unable to use the feedback area that gives me the exact record count in the workfile unless I CLOSE and REOPEN the file. I usually tend to design the workfile DDS so that it reflects the information being output on the report detail line (in other words I do not use a continuous text string). This approach comes in very handy when troubleshooting because the workfile contents remain untouched and available for review until the next time the report is requested. Obviously this would not be a suitable solution for a report that is generated multiple times by multiple users for in a short timeframe.
    0 pointsBadges:

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.


Share this item with your network: