× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On Fri, 2008-09-12 at 10:42 -0700, Adam West wrote:
I put in a new Printer file name and still, they both go to the one outq.

What is it I am doing wrong?

Let me restrict my answer to programming <grin />.

You do not mention either creating a new print file or issuing a changed
override. If for example, you just changed the rpg program to use file
QPRINT without changing anything else, then the program will run without
hangup (because QPRINT) exists, but output will go wherever QPRINT says
(quite likely *JOB, which I guess is OutqA). Your invoices will also
not be directed to the preprinted forms, so this would be pretty
obvious.

I suggest that you run the invoice print in the debugger. When the
print file is open, WRKJOB option 14 will show you the file which is
actually opened, and WRKJOB option 15 will show you the overrides
leading to the result. Drill down as necessary in option 15. If the
situation remains puzzling, post print screens of option 15 to the list.

Cheers,
Terry.


--- On Fri, 9/12/08, Terrence Enger <tenger@xxxxxxxxxxxxxxxx> wrote:

From: Terrence Enger <tenger@xxxxxxxxxxxxxxxx>
Subject: Re: Problem with ovrprtf
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Date: Friday, September 12, 2008, 2:33 PM

On Fri, 2008-09-12 at 06:20 -0700, Adam West wrote:
OK so in this case they are still all going to OutqB.
Where should I put the SECURE?
the first cl:

OVRPRTF FILE(REPORT) PRTTXT(BLANK) OUTQ(OutqA) +
FORMTYPE(INV) HOLD(*YES) SAVE(*YES) +
OVRSCOPE(*CALLLVL)

CALL PGM(ProgramA) /* PRINT A */


DLTOVR *ALL
CALL PGM(ProgramB)

ENDPGM

That is sufficient. However DLTOVR *ALL seems to me to be quite too
drastic: (1) It defaults to LVL(*ACTGRPDFN), which may be broader than
the OVRSCOPE(*CALLLVL) which you specified on the OVRPRTF. (2)
FILE(*ALL) may have a wider effect than just the OVRPRTF FILE(REPORT)
which you show us. So I suggest merely
DLTOVR FILE(REPORT) LVL(*CALLLVL)
to avoid imposing a double take on the next person who reads the
program.



(CL) ProgramB:

DLTOVR FILE(*ALL)
OVRPRTF FILE(REPORT) PRTTXT(BLANK) OUTQ(OutqB) +
FORMTYPE(INV) HOLD(*YES) SAVE(*YES) +
OUTPTY(1) OVRSCOPE(*JOB)

SECURE(*YES) on this override would redirect your printout as you want,
but I see a couple of difficulties here ...

(1) OVRSCOPE(*JOB) is too broad. It will redirect REPORTs for the rest
of the job. Subsequent REPORTs will be hard to find because on OutqB,
hard to read because on presumably preprinted formtype INV, and
expensive to the extent that the form is expensive.

(2) I think you meant PRTTXT(*BLANK).

(3) If OUTPTY(1) means that printing invoices is urgent, that is fine.
However, if perchance you merely want to minimize form changes, you
might find STRPRTWTR FORMTYPE(*FORMS) more effective.

I suggest that you create a separate print file for invoices and change
the invoice program to name that file. The whole question of a second
OVRPRTF goes away.

Cheers,
Terry.



Call PGM(ProgramB)

--- On Thu, 9/11/08, Terrence Enger <tenger@xxxxxxxxxxxxxxxx> wrote:

From: Terrence Enger <tenger@xxxxxxxxxxxxxxxx>
Subject: Re: Problem with ovrprtf
To: "Midrange Systems Technical Discussion"
<midrange-l@xxxxxxxxxxxx>
Date: Thursday, September 11, 2008, 9:13 PM

On Thu, 2008-09-11 at 14:54 -0500, John McKee wrote:
After rpgprogramA completes, DLTOVR printer_file_name

I am wondering if you are also including on the first OVRPRTF
SECURE(*YES). Doing that stops the override in program B from having
any effect.

Sorry, John, but I think it is the other way around, so to speak: it is
the (implicit) SECURE(*NO) on the the override in program B which makes
the override in program B ineffective. Consider ...

Outer program ...

pgm

/* three overrides, only the last one secure(*yes) */
ovrprtf one outq( a_outer )
ovrprtf two outq( b_outer )
ovrprtf three outq( c_outer ) secure(*yes)

/* call inner program */
call aa4382

endpgm

inner program ...

pgm

/* three overrides, only the second one secure(*yes) */
ovrprtf one outq( a_inner )
ovrprtf two outq( b_inner ) secure(*yes)
ovrprtf three outq( c_inner )

/* show results */
dspovr

endpgm

and screen images ...

Display All Merged File Overrides
Call level . . . . . . . . . . . : *
Type options, press Enter.
5=Display override details 8=Display contributing file overrides
Opt File Type Keyword Specifications
THREE PRT OUTQ(*LIBL/C_OUTER) SECURE(*YES)
TWO PRT OUTQ(*LIBL/B_INNER) SECURE(*YES)
ONE PRT OUTQ(*LIBL/A_OUTER)

Display Contributing File Overrides
File . . . . . . . . . . . . . . : THREE
Call level . . . . . . . . . . . : *
Type options, press Enter.
5=Display override details
Opt Level Type Keyword Specifications
7 PRT OUTQ(*LIBL/C_INNER)
6 PRT OUTQ(*LIBL/C_OUTER) SECURE(*YES)


Display Contributing File Overrides
File . . . . . . . . . . . . . . : TWO
Call level . . . . . . . . . . . : *
Type options, press Enter.
5=Display override details
Opt Level Type Keyword Specifications
7 PRT OUTQ(*LIBL/B_INNER) SECURE(*YES)

Display Contributing File Overrides
File . . . . . . . . . . . . . . : ONE
Call level . . . . . . . . . . . : *
Type options, press Enter.
5=Display override details
Opt Level Type Keyword Specifications
7 PRT OUTQ(*LIBL/A_INNER)
6 PRT OUTQ(*LIBL/A_OUTER)

hth,
Terry.

John McKee

Quoting Adam West <adamster@xxxxxxxxx>:

I have CL program-A,
pgm
program-A.

Overprtf outq(A)
Call rpgprogramA




Call program-B ( a CL PROGRAM)

Endpgm



This is program-B
pgm
Overprtf outq(B)
Call rpgprogramB
endpgm
BUT the outq of the second CL goes to the first outq - outq A

I need them to split. I have played around with the Ovrscope
parameter but then when I make that *job or *Calllvl, the both
outputs go to Outq B.

WHat am I missing to have them split off?



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.