Have you checked that the override is happening before the printer file is opened? If the external procedure is being called from the same program that is using the printer file then you will need to open it under user control. You can also check the scope of the override to see whether it is being made at job or call level. All the best Jonathan ============================================================= <i>I was told to just put it into the procedure and forget the CL</i> Why? OVRPRTF is CL, not RPG. By running as a CL module, you could have all of the native CL facilities for monitoring and handling CL exceptions. By running it in RPG, you are effectively needing to recreate everything that CL already has built in. Further, you must run it as interpreted CL rather than compiled CL -- you lose all of the potential for variable support as well as the performance that compilation provides. Note that this is referring to a CL <b>*MODULE</b> that would be bound with the RPG module, perhaps as a service program that could provide printer file overrides for many RPG modules. That would allow a fully customized function that would focus on printer overrides rather than a generic replacement for QCMD that needs to account for every possible interpreted CL command. The way you're doing it now requires every RPG program to have its own extra coding to handle whatever issues might arise. Why not just code it once in CL and bind it in? That's one of the whole reasons "ILE" exists. <i>...the OVRPRTF doesn't seem to be doing it's job.</i> Without seeing the OVRPRTF command there's no way to answer except by guessing. Obvious guesses should include activation group scoping. But because this is being executed in a bound procedure, the activation group shouldn't matter -- scoping to the job or the activation group should both work. Assuming, of course, that the "RunCL" procedure is prototyped and called properly... Show the coding. Show the prototype and the OVRPRTF command. Tom

Have you checked that the override is happening before the printer file is opened? If the external procedure is being called from the same program that is using the printer file then you will need to open it under user control. You can also check the scope of the override to see whether it is being made at job or call level. All the best Jonathan ============================================================= <i>I was told to just put it into the procedure and forget the CL</i> Why? OVRPRTF is CL, not RPG. By running as a CL module, you could have all of the native CL facilities for monitoring and handling CL exceptions. By running it in RPG, you are effectively needing to recreate everything that CL already has built in. Further, you must run it as interpreted CL rather than compiled CL -- you lose all of the potential for variable support as well as the performance that compilation provides. Note that this is referring to a CL <b>*MODULE</b> that would be bound with the RPG module, perhaps as a service program that could provide printer file overrides for many RPG modules. That would allow a fully customized function that would focus on printer overrides rather than a generic replacement for QCMD that needs to account for every possible interpreted CL command. The way you're doing it now requires every RPG program to have its own extra coding to handle whatever issues might arise. Why not just code it once in CL and bind it in? That's one of the whole reasons "ILE" exists. <i>...the OVRPRTF doesn't seem to be doing it's job.</i> Without seeing the OVRPRTF command there's no way to answer except by guessing. Obvious guesses should include activation group scoping. But because this is being executed in a bound procedure, the activation group shouldn't matter -- scoping to the job or the activation group should both work. Assuming, of course, that the "RunCL" procedure is prototyped and called properly... Show the coding. Show the prototype and the OVRPRTF command. Tom