OVRPRTF not working in procedure that is called

85 pts.
Tags:
CLP
RPGLE
Have an RPGLE program that calls a external procedure, which does an OVRPRTF (through a RunCL function), and then prints a report. The problem is, that the OVRPRTF doesn't seem to be doing it's job. Does this have something to do with the procedure? I originally had a CL that was called (from the RPG) which did the overrides, and then called the procedure and the report printed fine. But, I was told to just put it into the procedure and forget the CL, and now it doesn't work. Any suggestions? Thanks
ASKED: March 13, 2007  1:52 PM
UPDATED: March 19, 2010  6:47 PM

Answer Wiki

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

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

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.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Pouff
    I just come across some problem with OVRPRTF that does not work ! and I found the reason that is not that obvious... CL that I was running was compiled V4R5M00 way back in 2008 and the PRTFile was compiled last month using V5R4M00 user were telling me it does not print as before and after looking at the CL that looked Okay I thought of recompiling the CL and gest what ! Problem is solved. so next time you have a problem like "it use to work, but it does not anymore" just think that not same release ----> no same result !
    50 pointsBadges:
    report
  • TomLiotta
    CL that I was running was compiled V4R5M00 way back in 2008 and the PRTFile was compiled last month using V5R4M00 That in itself should have no bearing on the problem. Something else was almost certainly missed. Now, no one has any idea what the actual problem was. I'd like to suggest a future series of actions. IMO, a better procedure would have been to move the offending program to some safe library before submitting the compile. And any source information from the old object should have been tracked in order to grab the member info from source members. (Ideally, the source info would be gathered by a program so that human preconceptions wouldn't obscure details.) Then a recompile could be done with less chance of losing possible clues. The new compile would then "fix" the problem, and the cause could be determined later. Knowing the real cause allows searching for other programs that might have the same problem so they could be fixed before a production job had trouble. Tom
    125,585 pointsBadges:
    report
  • Teandy
    Try setting up your OVRPRTF command like this: OVRPRTF FILE(from_print_file) TOFILE(to_print_file) + OVRSCOPE(*JOB)
    5,860 pointsBadges:
    report

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.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following