RE: Weird Printer Issue

I feel like such an idiot. It was an OVRPRTF that lingered. I wrote a
command to replace the // PRINTER statement for a different reason, but
neglected to DLTOVR. Which would not have been an issue except that the
S36E package we use named every @#$% printer file the same name.

There are only a few OCL procedures that currently use the command, but a
few are frequently used processes. This is what made it so maddening
because it reared its head randomly (or so it seemed).

Thanks for slapping me upside the head, Jim.

Jerry C. Adams
IBM i Programmer/Analyst
I want to gain 1,500 or 2,000 yards, whichever comes first. George Rogers,
New Orleans Saints running back
--
A&K Wholesale
Murfreesboro, TN
615-867-5070


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim Franz
Sent: Tuesday, March 13, 2012 7:16 PM
To: Midrange Systems Technical Discussion
Subject: Re: Weird Printer Issue

An override printer file (ovrprtf) in the job stack could do this.

Also, because the // printer statement is optional, is it possible the
printer statement is not functional if the printer output file in pgm not
same as ocl printer name ?

Jim Franz

----- Original Message -----
From: "Jerry C. Adams" <midrange@xxxxxxxx>
To: "Midrange-L" <midrange-l@xxxxxxxxxxxx>
Sent: Tuesday, March 13, 2012 3:16 PM
Subject: RE: Weird Printer Issue

Also, meant to say that I did check the job log after the incident today
(when the invoice wanted to print at BB even though it should have been
directed to P7). There were no messages in the job log, and it shows the
//
PRINTER OCL statement explicitly referencing P7, but nothing later except
the normal stuff.

Jerry C. Adams
IBM i Programmer/Analyst
[I support efforts] to limit the terms of members of Congress, especially
members of the House and members of the Senate. - Dan Quayle
--