TCP/IP Printers ending
Glenn Novak
Just was looking for some help on a problem with TCP/IP Printers on an
AS/400 with V4R2. We just recently set up printers with TCP/IP. Our
network people give us the IP address and we create the device using
CRTDEVPRT using *lan and other common parameters.
The problem is that the writers keep ending by themselves. We get some
communication failure and they drop. We think the possibility might be
duplicate IP addresses. But our network crew claims this is not the case.
Does anyone have any suggestions on why this is happening? Perhaps someone
here had the same experience. Any advice would be greatly appreciated.
Glenn
Dawin Dziubinski
Glenn Novak <gno...@erols.com> wrote in message
news:87tfra$fd7$1...@bob.news.rcn.net...
hi
when you use crtdevprt *lan *ip your printer must support Printer Job
Language (PJL) - PCL5e
(mostly laser printer:( )
davin
pmca...@oneill.com
We have the same problem with HP4, 4+, 5, 4000, 4050 printers. They
usually fail on larger print jobs for some reason. Has this been your
observation? It has been this way on V3R2, V4R1,2,3 for us, no PTF's
make any difference. Unfortunately, I don't have a solution but if I
had a little more time I would look at finding precise reasons writers
for lan attached printers to fail and capturing packets returning from
the printer to the host before and during the writer failure to check
if some type of timeout or error is occuring.
I will be capturing the spool files that cause the writers to fail and
reviewing their content to see if there is some character string
causing grief. If this yields nothing, another (remote)possibility is
the *TRANSFORM WSCST object (use RTVWSCST *TRANSFORM for *HP4 mfrtypmdl
entry and save it to a test library for examination using SEU - don't
make changes to your production WSCST). It is within the WSCST that the
rules for performing the host print transform take place for the driver
and maybe therein lurks some problem.
If I find a solution, I will let you know. Likewise, please email me
anything you find out. Much obliged.
Peter McAneny
Sent via Deja.com http://www.deja.com/
Before you buy.
Rodney Johnson
TCP/IP. Checkout the printer writer's joblogs. There should be messages in
the joblog indicating some of what is going on. Also check into the
following items:
1. On the printer set the Idle Timeout to 3600 secs (or 0 (if allowed) to
disable) or some other value dependent on step 5 below.
The reason for this is so that the printer will not terminate the connection
with the AS/400.
A timeout from the printer will result in a terminating error and the file
will be set to HLD or RDY (if a file is printing); and the writer will end.
The equivalent timer for the Lexmark print servers is the End of Job
Timeout. It should be set to 0 (disabled).
The equivalent timer for the IBM network printers is the Port Timeout. I
believe it's maximum value is 300, and cannot be disabled.
2. On the printer, the processor timer (called job timeout or wait timeout)
should be disabled or set to maximum (usually 300 secs) since individual
pages may have a delay in transmitting to the printer due to transforming
considerations.
3. The recommended setting for Inactivity Timer should be set at some
value other than *NOMAX so that the
connection will be closed during periods of no activity.
4. The activation timer should be set to a value large enough to prevent
posting of intervention errors due to TCP/IP transmission delays and printer
processing delays. The default setting of 170 secs is usually large enough
to accomplish this unless you send large files to a printer with a slow
processor that has a lot of memory. Increasing the activation time will
prevent unwanted intervention errors but that time will have to pass before
you will get an desired intervention error. Note that intervention errors do
not stop the print process. If the Printer Error Message parameter in the
Device Description for the writer was set to *INQ, then the intervention will
require an operator input to retry or to cancel the writer. If the parameter
was set to *INFO, then the driver will continue to retry until the
connection has been established or the TCP/IP has closed the socket or, in
the case of a slow printer processor, the proper response is obtained which
is either the printer is online or that the printer has received all the
data. If the connection was eventually successful the intervention message
will be attempted to be removed from the message queue, and process will
continue.
5. When the Idle Timeout on the printer (step 1 above) is set to some value
(hopefully large), the printer will close the socket if the printer hasn't
processed any communication from the host within the Idle Timeout limit.
This can happen if the printer has a large buffer, and it is filled with data
to print. To prevent this from happening, the TCP/IP Keep-Alive value on
the AS/400 (via the CHGTCPA command) should be set to a value less than the
printer Idle Timeout value. This will cause a poll to be sent to the printer
before the printer times out. We want this value to be as large as possible
to prevent unnecessary network traffic. The recommend value if step 1 is
done (the 3600 secs), is 50 minutes.
Glenn Novak wrote:
> Hi all,
>
> Just was looking for some help on a problem with TCP/IP Printers on an
> AS/400 with V4R2. We just recently set up printers with TCP/IP. Our
> network people give us the IP address and we create the device using
> CRTDEVPRT using *lan and other common parameters.
> The problem is that the writers keep ending by themselves. We get some
> communication failure and they drop. We think the possibility might be
> duplicate IP addresses. But our network crew claims this is not the case.
> Does anyone have any suggestions on why this is happening? Perhaps someone
> here had the same experience. Any advice would be greatly appreciated.
>
> Glenn
--
Rodney A Johnson
Technical Team Lead for AS/400 Spool
Dept GJC
IBM Rochester, Minnesota
The contents of this message express only the sender's opinion.
This message does not necessarily reflect the policy or views of
my employer, IBM. All responsibility for the statements
made in this Usenet posting resides solely and completely with the
sender.
Glenn Novak
know what happens. Thanks again.
Glenn
Rodney Johnson <rjoh...@rchland.ibm.com> wrote in message
news:38A2CE3E...@rchland.ibm.com...
Sean Kemball
box, tried the latest PTFs, device timeouts, *WSCST customisations, remote
OUTQs, CRTDEVPRT, the works... no luck. Placed a call on IBM and spent
thousands of dollars getting "support" from the nearest expert some 5
timezones away (IBM support here (NZ) is pretty thin on the ground) - no
luck at all. My guess is because we need to print to the (Lexmark) printer
(attached to a Lexmark print server) from NT as well as AS/400, it all gets
too hard.
I'm currently holding out hope that our 4.4 upgrade next month will sort the
problem, or else I'll put in a hardware solution like the print boxes from
Intelligent.
Given that the AS/400 Printing redbook is in about it's fifth or sixth
version I'm assuming that this is another thing with OS/400 that works after
five releases...
Sean
Glenn Novak <gno...@erols.com> wrote in message
news:88001l$2vj$1...@bob.news.rcn.net...
> THANKS TO ALL for your responses. I will try your suggestions and let you
> know what happens. Thanks again.
>
> Glenn
>...
Rodney Johnson
same as the old twin-ax connected printers. Printer dedication basically
doesn't exist. Therefore certain types of recoveries can nolonger be done, as
old assumptions can nolonger be made. MANY AS/400 users have had trouble
getting the configuration correct and get the right fixes on BOTH AS/400
AND the PRINTER or PRINT SERVER. But, those users have finally got it working
to their satisfaction.
From you description, your options are:
1) LexMark driver. This is not a "routable" protocol, but can be routed
through some routers. Unfortunately, I am unable to find out what routers do
or do not work, and LexMark support is of no help at all. This solution is the
closest to a dedicated LAN printer that you will get. A key here is to ensure
you have the latest micro-code updates for your LexMark printer server.
I believe you need a MarkNet XLe or MarkNet Pro (I don't think the older models
can be "fixed" completely).
2) HP PJL driver. Here you need to make sure that your printer supports
PCL5e. Your LexMark printer server probably does support bi-directional PJL on
some TCP/IP port (but you need to check. I suspect it would be 9100). Another
major factor in configuration is setting up TCP/IP correctly on the AS/400
(along with printer device description, and the printer itself). I've posted
these requirements many times (a list of "5" items).
3) Remote writer support (LPR/LPD). This is what many use. This has the least
amount of support regarding error recovery handling, and support for a printer
in general. It was designed for sending files from system to system NOT system
to printer. One of the largest complaints was the lack of page range support.
A transform exit example program in QUSRTOOL can solve that issue. Many are
using it with very few problems. I have a SAVF containing the source and the
compiled code that I can send you if you are interested.
4) Printer driver exit. This exit interface was designed to allow customers to
write their own printer drivers or for printer vendors to write drivers for
their own printers. There is so much hipe about the AS/400 should be "open
sourced" and be made available on PCs etc. But I sure don't see anyone writing
to this printer driver exit (I know of only ONE third party vendor who has
written to this interface). Anyway, I have an example program that
demonstrates some of this interface. It is a very simple
LPR/LPD implementation that has a few more built in features that the remote
driver (LPR) does not have. There is support for page ranges, separator pages,
device information is passed to HPT, job accounting, and a few other items.
I also have this in SAVF form and have been giving this out to those
interested. As yet I have had no feed back concerning the usefullness of the
printer driver example. Not sure that I can assume that no news is good news.
As you mentioned, red book AS/400 Printing V has printer device configuration
information.
Sean Kemball wrote:
--
Bernd Schaefers
Thanks!
--
Bernd Schäfers
bscha...@gmx.net
"Rodney Johnson" <rjoh...@rchland.ibm.com> schrieb im Newsbeitrag
news:38AC0CB0...@rchland.ibm.com...
[...]
> 4) Printer driver exit. This exit interface was designed to allow
customers to
> write their own printer drivers or for printer vendors to write drivers
for
> their own printers. There is so much hipe about the AS/400 should be
"open
> sourced" and be made available on PCs etc. But I sure don't see anyone
writing
> to this printer driver exit (I know of only ONE third party vendor who has
> written to this interface). Anyway, I have an example program that
> demonstrates some of this interface. It is a very simple
> LPR/LPD implementation that has a few more built in features that the
remote
> driver (LPR) does not have. There is support for page ranges, separator
pages,
> device information is passed to HPT, job accounting, and a few other
items.
> I also have this in SAVF form and have been giving this out to those
> interested. As yet I have had no feed back concerning the usefullness of
the
> printer driver example. Not sure that I can assume that no news is good
news.
[...]
Bernd Schaefers
I would be VERY interested in your example program.
Sean Kemball
Rodney Johnson <rjoh...@rchland.ibm.com> wrote in message
news:38AC0CB0...@rchland.ibm.com...
> Sean, What EXACTLY have been your problems? LAN attached printers are not
the
> same as the old twin-ax connected printers. Printer dedication basically
Understood. I'm fairly familiar with printing in a number of different
environments, and I don't think I was trying to treat them like twinax
printers. Most of the problems we had were in finding a tradeoff between
print integrity (including font, tray-select, and forms handling) up against
plain old getting-the-data-to-the-printer problems. IBM couldn't identify
why the AS/400 was timing out talking to the print server (or through an NT
box), for example. We spent a bit of time poring over comms traces and
joblogs, to no avail. There is no network problem between the AS/400 and the
print server - my logic is that if I can telnet the print server from the
AS/400, then I should be able to print to it.
> doesn't exist. Therefore certain types of recoveries can nolonger be
done, as
> old assumptions can nolonger be made. MANY AS/400 users have had trouble
> getting the configuration correct and get the right fixes on BOTH AS/400
> AND the PRINTER or PRINT SERVER. But, those users have finally got it
working
> to their satisfaction.
Any acceptable solution for me must be a) functional, b) repeatable across a
range of equipment and environments, and c) not require cryptic tinkering of
the form of "try this, it *may* work". I accept that this isn't easy stuff
(sadly - I do think it should be, though), but I do expect that it is well
understood, and that a good reason can be found for every bit of trouble.
> From you description, your options are:
> 1) LexMark driver. This is not a "routable" protocol, but can be routed
> through some routers. Unfortunately, I am unable to find out what routers
do
> or do not work, and LexMark support is of no help at all. This solution
is the
> closest to a dedicated LAN printer that you will get. A key here is to
ensure
> you have the latest micro-code updates for your LexMark printer server.
> I believe you need a MarkNet XLe or MarkNet Pro (I don't think the older
models
> can be "fixed" completely).
We have XLe's, but weren't trying to use LexLink. I believe in standards,
and TCP/IP should work fine.
> 2) HP PJL driver. Here you need to make sure that your printer supports
> PCL5e. Your LexMark printer server probably does support bi-directional
PJL on
> some TCP/IP port (but you need to check. I suspect it would be 9100).
Another
> major factor in configuration is setting up TCP/IP correctly on the AS/400
> (along with printer device description, and the printer itself). I've
posted
> these requirements many times (a list of "5" items).
Yup, the printers are fine on all of these issues, and the print server port
numbers are correct (checked with LexMark). We tried several parameter
changes for the AS/400 *DEVD, including ports and timeouts. No luck.
> 3) Remote writer support (LPR/LPD). This is what many use. This has the
least
> amount of support regarding error recovery handling, and support for a
printer
> in general. It was designed for sending files from system to system NOT
system
> to printer. One of the largest complaints was the lack of page range
support.
> A transform exit example program in QUSRTOOL can solve that issue. Many
are
> using it with very few problems. I have a SAVF containing the source and
the
> compiled code that I can send you if you are interested.
No page range support, dodgy font support, no tray-select,.... Nope this
isn't the answer. I may be able to get around it by transforming print
output manually, mucking about with exit programs, then using RMTOUTQ
support to get the finished product to the printer, but why bother? We half
do this now with a product called Create/Print, which transforms (and form
merges) some of our output to Postscript, then we simply move it to an NT
lpd quque using RMTOUTQ support. This would serve our other needs well too,
but at over US$1000/seat, seems a bit of overkill for some simple
non-forms-merging printing. Even the hardware solution is cheaper.
> 4) Printer driver exit. This exit interface was designed to allow
customers to
> write their own printer drivers or for printer vendors to write drivers
for
I don't even think I should have to muck around with *WSCSTs (even though I
did, to no avail). When the world moved away from dedicated twinax-attached
printers, I believe it was IBM's responsibility to provide native support
for a reasonable range of printers accessible over IP. Basically, I'd like
to create a RMTOUTQ, specify HPT as *LEXOPTRA, and have it handle everything
from there, respecting print attributes on the way.
:-)
Sean
Rodney Johnson
the network has rather slow traffic. Make sure you have a reasonable amount of
memory for the *SPOOL storage pool. The hard part is determining what is
"reasonable". The host print transform function takes a fair amount of
memory. You cannot get by with a couple hundred kilobytes like you did for
twin-ax attached printers. Starting out with 5 megabytes is a good choice. If
you have a lot of *IPDS attached printers (requireing PSF/400) and *IP attached
printers using HPT, you may need to increase the amount of memory from 5
megabytes to maybe as high as 20 (depends upon how active your printing
evironment is).
It would be a good idea to make sure your printer device description has the
inactivity timer set to something like *SEC15 (releases connection with printer
if no files are available to print within 15 seconds).
Increasing the TCP/IP job timeout on your printers would be a good idea as
well. I do believe that the LexMark printers are capable of having the timeout
disabled (I believe this setting must be done by telneting into the LAN printer
server). I realize that in most cases these printers are usually shared with
other systems, and setting the timeout to NOMAX is not acceptable.
Do not bother doing a HLDWTR and expect the RLSWTR *CURRENT to work. WHY.
Because if the TCP/IP job times out, we cannot assume that we can just
reconnect and continue printing where we left off. Another system(s) could
have gotten a connection with the printer and printed one or more files. This
would divide the printed file that the AS/400 was working on. Use of job
separators becomes less useful as well. Loss of a connection with a printer
between files for a job could end up with other systems printouts being in the
middle of an AS/400's job's printouts.
Make sure you have the latest version of the microcode for you LexMark boxes.
I do not recall any specific problems, but LAN printer servers have been known
to cause rather bizzarre situations that are not obvious (looks like an AS/400
problem).
As to fonts and rotation, this is usually a problem with the printer files. At
one time you may have been printing on a printer with a no print border (at
least with twin-ax connection). Most printers attached via TCP/IP HAVE a no
print border. This makes the available printed area smaller, and thus HPT may
start CORing (usually because most printer files have PAGRTT(*AUTO)). If you
were use to PSF and the CORing of *AFPDS spooled files, you will find that HPT
does not SUPPORT CORing of *AFPDS spooled files. In this case, you would need
to change the page rotation AND the font size in order to get the same affect
as COR.
If you printed via twin-ax without HPT (in the past), then the font
substitution is most likely quite different with HPT. The WSCSTs on the system
(corresponding to the MFRTYPMDLs) were setup to try and give similar results
(as twin-ax). Unfortunately, most of the similar results require changes to
the printer files being used by your applications. IBM could not change these
printer files because we have no way of knowing who does what form or
printing. Thus switching from twin-ax to LAN printing can be quite a
nightmare. I agree that it would be nice to not have to go through a lot of
changes to make things "work the way the use to". Unfortunately that is not
possible.
I'll include that list I mentioned in my previous post. Go through that list
and see if the IBM support people you worked with missed something. We have a
LOT of customers using the HP PJL driver support with LexMark printers and
printer servers. I find it hard to believe that your environment will not
work.
> 1. On the printer set the Idle Timeout to 3600 secs (or 0 (if allowed) to
> disable) or some other value dependent on step 5 below.
> The reason for this is so that the printer will not terminate the connection
> with the AS/400.
> A timeout from the printer will result in a terminating error and the file
> will be set to HLD or RDY (if a file is printing); and the writer will end.
>
> The equivalent timer for the Lexmark print servers is the End of Job
> Timeout. It should be set to 0 (disabled).
> The equivalent timer for the IBM network printers is the Port Timeout. I
> believe it's maximum value is 300, and cannot be disabled.
>
> 2. On the printer, the processor timer (called job timeout or wait timeout)
> should be disabled or set to maximum (usually 300 secs) since individual
> pages may have a delay in transmitting to the printer due to transforming
> considerations.
>
> 3. The recommended setting for Inactivity Timer should be set at some
> value other than *NOMAX so that the
> connection will be closed during periods of no activity.
>
>
> 4. The activation timer should be set to a value large enough to prevent
> posting of intervention errors due to TCP/IP transmission delays and printer
> processing delays. The default setting of 170 secs is usually large enough
> to accomplish this unless you send large files to a printer with a slow
> processor that has a lot of memory. Increasing the activation time will
> prevent unwanted intervention errors but that time will have to pass before
> you will get an desired intervention error. Note that intervention errors do
> not stop the print process. If the Printer Error Message parameter in the
> Device Description for the writer was set to *INQ, then the intervention will
> require an operator input to retry or to cancel the writer. If the parameter
> was set to *INFO, then the driver will continue to retry until the
> connection has been established or the TCP/IP has closed the socket or, in
> the case of a slow printer processor, the proper response is obtained which
> is either the printer is online or that the printer has received all the
> data. If the connection was eventually successful the intervention message
> will be attempted to be removed from the message queue, and process will
> continue.
>
> 5. When the Idle Timeout on the printer (step 1 above) is set to some value
> (hopefully large), the printer will close the socket if the printer hasn't
> processed any communication from the host within the Idle Timeout limit.
> This can happen if the printer has a large buffer, and it is filled with data
> to print. To prevent this from happening, the TCP/IP Keep-Alive value on
> the AS/400 (via the CHGTCPA command) should be set to a value less than the
> printer Idle Timeout value. This will cause a poll to be sent to the printer
> before the printer times out. We want this value to be as large as possible
> to prevent unnecessary network traffic. The recommend value if step 1 is
> done (the 3600 secs), is 50 minutes.
>
--