There is an attribute on a print file for SAVE (*YES or *NO). Once the report is printed, then if *YES, it will save it. *SAVE identifies a report THAT HAS PRINTED and is now being saved. It cannot go to the queue as SAVE When you create a print file you can have the save option set to *YES like this: <pre>CRTPRTF FILE(YOURLIB/PRTFILE) SAVE(*YES)</pre> If you wish to temporary override a print file that is already on the system you can use the override print file command like: <pre>OVRPRTF FILE(QSYSPRT) TOFILE(QSYS/QSYSPRT) SAVE(*YES)</pre> If you are using a system print file, you may have to run the program once to see which print file is being used in order to do the override to the correct print file. You could also do a change to the print file, but if you do this it will be system wide and all user spool files will be set to save. I would recommend that you copy the print file to a user library, change that print file and then place the user library first in you library list. <pre> CHGPRTF FILE(YOURLIB/QSYSPRT) SAVE(*YES)</pre> -------------------------- Absolutely right on Charlie Brown The OVRPRTF is often placed in the CL just before the call to the RPG program since it must be issued before the print file is opened by the program. Phil ========================================================= In general, don't copy a system print file such as QSYSPRT to a user library and then place the user library at the top of the library list. Rather, duplicate the file with a different name and use the new name in your programs. Placing a version of a system printer file above IBM versions can interfere with system print functions after upgrades. Generally, system printer files (QSYSPRT, QPQXPRTF, etc.) shouldn't be used for in-house programming nor are they needed. A simple CRTPRTF command can create a printer file with whatever customization is needed. IBM has changed printer file definitions in the past. An unexpected change in the future can potentially mess up application output. Unlikely, yes; but why avoid using CRTPRTF and getting exactly what you want without overrides? Tom

There is an attribute on a print file for SAVE (*YES or *NO). Once the report is printed, then if *YES, it will save it. *SAVE identifies a report THAT HAS PRINTED and is now being saved. It cannot go to the queue as SAVE When you create a print file you can have the save option set to *YES like this: <pre>CRTPRTF FILE(YOURLIB/PRTFILE) SAVE(*YES)</pre> If you wish to temporary override a print file that is already on the system you can use the override print file command like: <pre>OVRPRTF FILE(QSYSPRT) TOFILE(QSYS/QSYSPRT) SAVE(*YES)</pre> If you are using a system print file, you may have to run the program once to see which print file is being used in order to do the override to the correct print file. You could also do a change to the print file, but if you do this it will be system wide and all user spool files will be set to save. I would recommend that you copy the print file to a user library, change that print file and then place the user library first in you library list. <pre> CHGPRTF FILE(YOURLIB/QSYSPRT) SAVE(*YES)</pre> -------------------------- Absolutely right on Charlie Brown The OVRPRTF is often placed in the CL just before the call to the RPG program since it must be issued before the print file is opened by the program. Phil ========================================================= In general, don't copy a system print file such as QSYSPRT to a user library and then place the user library at the top of the library list. Rather, duplicate the file with a different name and use the new name in your programs. Placing a version of a system printer file above IBM versions can interfere with system print functions after upgrades. Generally, system printer files (QSYSPRT, QPQXPRTF, etc.) shouldn't be used for in-house programming nor are they needed. A simple CRTPRTF command can create a printer file with whatever customization is needed. IBM has changed printer file definitions in the past. An unexpected change in the future can potentially mess up application output. Unlikely, yes; but why avoid using CRTPRTF and getting exactly what you want without overrides? Tom