How does OVRPRTF scope to called jobs?

[Guest.Visitor]

I have a mainline CL that has a<pre>OvrPrtF file(*prtf) copies(1) hold(*yes) outq(myoutq) </pre>This works exactly how I want it to for most of the programs, but during one called CL program especially, I want to delete/ignore this override. If I put a<pre>DLTOVR FILE(*PRTF)</pre> in the called CL, it results in an error "no overrides exist at this level". I take it that since the override was issued in the calling CL, the called CL can't delete it with the default scoping parameter. Is there a scoping parameter that will work? The ideal solution is to delete the override only for the life of the called CL. I am thinking that the only way to get around this is to delete the override before the called CL, then restore it after. Are there any other ways to accomplish this? Bill

[Guest.Visitor]

<font size=-1 color="#0000CC">On Friday, May 14, 1999, 03:31 PM, Bill Robins wrote: I have a mainline CL that has a<pre>OvrPrtF file(*prtf) copies(1) hold(*yes) outq(myoutq) </pre>This works exactly how I want it to for most of the programs, but during one called CL program especially, I want to delete/ignore this override. If I put a<pre>DLTOVR FILE(*PRTF)</pre> in the called CL, it results in an error "no overrides exist at this level". I take it that since the override was issued in the calling CL, the called CL can't delete it with the default scoping parameter. Is there a scoping parameter that will work? The ideal solution is to delete the override only for the life of the called CL. I am thinking that the only way to get around this is to delete the override before the called CL, then restore it after. Are there any other ways to accomplish this? </font> Bill, Not sure you can do a selective delete like that, but can that particular CL do another override to suit itself? Like: <pre> OVRPRTF FILE(*prtf) HOLD(*NO) OUTQ(AnotherOutq) SECURE(*YES) </pre> Derek

[Guest.Visitor]

Derek, That is a distinct possibility for one of the other called CL's I am working with, but not this one. What makes this frustrating is that I want the RUNQRY command to honor the PRTDEV parameter, but it doesn't. I guess I will continue with the CHGSPLFA and RLSSPLF commands. Bill Derek Butland wrote: <font size=-1 > color="#0000CC">Bill, Not sure you can do a selective delete like that, but can that particular CL do another override to suit itself? Like: <pre> OVRPRTF FILE(*prtf) HOLD(*NO) OUTQ(AnotherOutq) SECURE(*YES) </pre> Derek </font>

[Guest.Visitor]

On Monday, May 17, 1999, 07:31 AM, Bill Robins wrote: What makes this frustrating is that I want the RUNQRY command to honor the PRTDEV parameter, but it doesn't. OUTQ supercedes any DEV specs. You would need to specify OUTQ(*DEV) on the OVRPRTF. If you prompt CHGSPLFA for the previously spooled query report, you'd likely see that the PRTDEV is reflected in the DEV parameter. To effect the override loss just for a specific program, create the other program in a separate named activation group. Regards, Chuck Comments provided "as is" with no warranties of any kind whatsoever.