Comments on: OVRPRTF not chaning OUTQ

By: elterrifico

elterrifico — Thu, 21 Jan 2010 16:59:08 +0000

Problem solved. The override was working properly all along. Later in the job there was a program that moved all the entries from one OUTQ to another. I only got to look at the results after the job had completed which made it look like it wasn’t being placed in the correct OUTQ. It was, it was just getting moved later.

Thanks again for everyone who contributed their thoughts on the matter.

By: teandy

teandy — Thu, 21 Jan 2010 16:38:05 +0000

Are any of the other over rides set up with SECURE(*YES)?

By: elterrifico

elterrifico — Thu, 21 Jan 2010 14:01:20 +0000

In trying your suggestions, I noticed something this morning that I overlooked yesterday. The user data portion of the over ride is taking effect as the spool file has the overriden user data on it. It is only the outq part of the override that is not taking effect. I also verified that there are no overrides on the print file to another outq. There are existing overrides on the file, but they all point to the same outq. Interestingly those overrides all seem to work correctly. The problem is apaarently between the last successful override and the one I am having a problem with which is where I am looking now. Any more thoughts on what to look for are most welcomed. I will let you know if I find the problem. Thanks.

By: elterrifico

elterrifico — Thu, 21 Jan 2010 13:45:43 +0000

Thanks everyone for the input.

Teandy, that was the first thing I considered, but after checking that the calling program ran in the caller’s activation group, changing the scope to *JOB shouldn’t (in theory) make a difference. Unfortunately it is not easy to set up test conditions for this job, so I don’t want to make unnesseary changes if I don’t think they will work. However, if I get desperate I may give that a shot.

Tom, I should have known you’d pick up on that, you are always so thorough in your analysis. The override is part of an IF/then/else structure. There is no way for any of the lines between 3600 and 5800 to run.

Phil, I did check for DLTOVRs, but I didn’t consider an existing override. My thought was that the new override would take precedence over an existing override. I never considered that an existing override could keep a new override from taking effect. I’m going to look into that further.

Thanks again to everyone for your contributions

By: philpl1jb

philpl1jb — Thu, 21 Jan 2010 03:07:43 +0000

Some ideas
1. if there is a dltovr(*all) that would be relevant- even in called programs
2. if there is an override already on this file setting the outq you will not change it.
3. if the file is open prior to the ovrprtf it will not change
4. you are setting the outq for this file at the activation group level.
Phil

By: tomliotta

tomliotta — Wed, 20 Jan 2010 23:52:31 +0000

3600 – OVRPRTF…
5800 – CALL…

Just to be sure, there wouldn’t happen to be lines in the CL between 3600 and 5800 that are relevant, would there? (It has to be asked.)

Tom

By: elterrifico

elterrifico — Wed, 20 Jan 2010 14:16:40 +0000

My question got truncated when I posted it. Here’s the complete question:

I have a program where the OVRPRTF command does not seem to be taking affect. The output is going to the job’s default outq and not the overridden outq. The following are consecutive lines from the job log:

3600 – OVRPRTF FILE(XX6300PR) TOFILE(XX6300PR) OUTQ(PFSUB04A) USRDTA(‘C PRINT’)
5800 – CALL PGM(XX6300RR) /* The CALL command contains parameters */

.
Here’s what I verified:
• XX6300PR is the PRTF in XX6300RR
• The calling program runs in the default activation group
• The called program (XX6300RR) runs with *CALLER activation group.
• *PUBLIC has *USE authority to the outq (PFSUB04A).
• The outq (PFSUB04A) is in job’s library list.
Any thoughts on what I am missing? Based on the activation groups of the 2 programs, the override scope should be OK.