Hi,
Jerry C. Adams
> First, about two weeks ago I connected a PC printer in our
warehouse manager's office to our System i (V5R1) via PC5250 printer
emulation. Worked great - until yesterday.
> The reports, documents, etc., for the two girls in the office
started printing to this new printer (BB), even though the OCL or CL
explicitly referenced a different printer. I even changed a
procedure so that the
Kirk
> CHGS36 cmd and the 2 options S/36 display IDs, S/36 printer
IDs and make sure the device names in fact line line up the way you
expect it to.
Jim Franz
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 ?
Steven Spencer
Right. Notice that you mentioned "OCL or CL" so there could be some
contention. One possibility, very easy to test, would be to change
the OCL // PRINTER to OVRPRTF, (which is legal to do) since that
would not contend with a previous CL statement. (btw, Is there a
"clear" command for OVRPRTF ?)
Is this all running via Client Access ? In general, the IBM
Rochester techies would take a PMR on this, and walk you through a
few ideas. Even if is something silly, they tend to be quite helpful.
I just ran into a situation where I had to change S36 device
descriptions, after a port switch. Sometimes you try to delete the
spool writer and output queue and then bring them back up by
auto-config, and change the CHGS36 device by hand, if necessary. If
somehow the rock solid OS got confused, this acts as a reset.
Steven Spencer
Queens, NY
midrange.com
