The x'0C's are coming from the print file. You can fix the problem by setting overflow at appropriate points in the program writing to the print file.

It's been years and years and years, but I believe the method I used was to force overflow before writing the line of control instructions that broke to the next label and closed the control stream. The form feed (0d 0a 0d 0c) was then within the control stream and the printer just ignored it. OVRPRTF page length to 255 and OL to 255.

Another way would be to make the print file *USERASCII and just do all the translation within the program.

Another possible solution: Write directly to the spool file API's and bypass the print file altogether.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of DrFranken
Sent: Thursday, July 19, 2012 9:58 PM
To: Midrange Systems Technical Discussion
Cc: franz400
Subject: Re: Printronix Label Printers.

This is a 7000 series printronix with using PGL (I think) board doing the graphics. The emulation is 'None' or simply translate EBCDIC to ASCII (QWPDEFAULT). The printer has an LPR daemon in it so we can use either TSLPRD or a remote output queue to print directly to the d1prn queue as you suggest. Either way IBM i IS counting lines and inserting 0C Form Feed characters when it 'thinks' there is a page break and then tossing one final 0C at the end of the run. That last 0c can be ignored by the printer and we thought that was our only issue until we discovered that occasionally the 0C's land in just the wrong spot causing a row of labels to print twice. This is with *AUTOCUT setting.
If we use *CONT it's MUCH worse as it inserts many CR LF pairs at the end and makes a real mess of forms alignment.

So far nobody has been able to tell us how to make IBM i stop doing ANY page handling. Scott Klements suggestion has thus far been the best, I just have to tweek and then implement that program. :-)

- Larry


On 7/19/2012 9:35 PM, franz400 wrote:
Larry,
You did not mention which options you took in configuring both printer
and the i devd or outq or even which Printronix model.
I don't want to throw out guesses, but having setup a number of
Printronix and other label printers over the years, the following has
generally worked for me.

1. If you've been in a support call then assume you have been through
all the variations like (if your model supports this-putting the
printer in Epson mode and using one of the recommended Epson
mfrtypmdl's on the system) or the IBM Proprinter mode and mfrtypmdl... or others in the list.

2. This has been a common problem... what is between the printer and
the i (if anything) (you verified the 0C from the system and not the
hardware in between.

are you using the 'd1prn' RMTPRTQ (if this is a remote outq)?
http://www-01.ibm.com/support/docview.wss?uid=nas1b49aa3cf3ce97d0d8625
65c2007d4393


Printronix recommendations - including notes on certain printer data
streams (bottom of doc)
http://www-01.ibm.com/support/docview.wss?uid=nas10fc2dc92fbe97ece8625
69c1007a9793

jim franz


----- Original Message -----
From: "DrFranken" <midrange@xxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Thursday, July 19, 2012 5:27 PM
Subject: Re: Printronix Label Printers.


Scott,

This is indeed intriguing.

The logic would have to be "Replace any 0C with 0A unless it is the
VERY last character in the print stream. In that case don't send
anything whatever."

Can you point to an example of such a program?

Thanks!

- Larry

On 7/19/2012 5:09 PM, Scott Klement wrote:
Hello,

Sorry, I've not used Printronix label printers... (Actually, I
have... but it was 1980ish type stuff that didn't exhibit this
problem.)

Having said that... I wonder if you couldn't write a USRDTATFM exit
program? It could call the normal HPT API to do the data transform,
but could search the output buffer for the unwanted x'0c' and remove
it as desired. That would eliminate the problem you're describing,
would it not?

-SK


On 7/19/2012 4:02 PM, DrFranken wrote:
Is anyone using Printronix label printers LAN connected for the
exclusive purpose of printing pre-formatted labels?

We have beat this problem to death, IBM is out of ideas (up to "You
can pay for a consultant.")

Problem is that IBM i (5.4) is sending an occasional '0C' (feed
character.) When that is in the middle of the label command
language stream it's fine because the printer's control process ignores it.
However when it happens to be in the ASCII bits between labels
where the 'EXECUTE FORM' is sent, then it causes that row of labels
to print Twice!

Attempting to use a WSCST object to replace the 0C with nothing (i.e.
DATA = ''X) fails because ''X and '00'X work out to the same thing.
So the 00 appears instead of the 0C and that sends the printer
wacko and it prints errors instead of labels.

I tried to be cute by replacing the 0C with a 0A because the 0C was
overlaying 0A. Worked for printing BUT the system always sends an
0C at the end of the print file so now it sends 0A and that wacks
the alignment by one line for each label job.

SOMEBODY has to be using these printers??? Thoughts?

- Larry "DrFranken" Bolhuis.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)
mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
a moment to review the archives at
http://archive.midrange.com/midrange-l.



--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.




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.