IP printing to a HP 4000
Thomas Hauber
However when we print to it via IP from our AS400 (running V4R2), it
will end the writer abnormally after several pages have printed. We
have been unable to isolate the problem.
Could this perhaps be a driver issue on our AS400? Below is the command
we used to create the *LAN printer device:
CRTDEVPRT DEVD(CSLZ) DEVCLS(*LAN) TYPE(3812) MODEL(1) +
LANATTACH(*IP) PORT(9100) ATTACH(*DIRECT) +
ONLINE(*YES) FONT(11) FORMFEED(*AUTOCUT) +
PRTERRMSG(*INQ) MSGQ(QSYSOPR) +
TRANSFORM(*YES) MFRTYPMDL(*HP6) +
CHRID(*SYSVAL) +
RMTLOCNAME('192.168.100.30') +
SYSDRVPGM(*HPPJLDRV) TEXT('CSLZR *LAN +
printer description')
We decided to use the MFRTYPMDL(*HP6), because there was no *HP4000.
Could this be the problem?
Any help would be appreciated.
--
NOTICE TO BULK E-MAILERS: Pursuant to US Code, Title 47,
Chapter 5, Subchapter II, 227,
and all nonsolicited commercial e-mail
sent to this address is subject to a download and
archival fee in the amount of $500 US.
Double Down
noticing the same issue. I am using IBM 4324's, and the appropriate
drivers. The writers seem to drop for no reason at all.
Thomas Hauber wrote in message <36DF011F...@iname.com>...
Rodney Johnson
*LAN attach printers (or any LAN attach device for that matter), there is a
whole lot more situations that have to be considered. With twin-ax attached
printers, the writer could assume that if it recovered from an error that it
could pick up where it left off. With LAN attach printers, that assumption
is nolonger valid. If there is a communcations error, and a connection is
lost, another system could get a connection and print before our writer can
reconnect and continue where it left off. We need to guarantee that the
WHOLE file is printed and TOGETHER (not separated by other printed
material). What follows is a series of settings and configurations to
considered when using the HP PJL driver support:
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.
Thomas Hauber wrote:
> ------------------------------------------------------------------------
>
> Thomas Hauber <t...@iname.com>
>
> Thomas Hauber
> <t...@iname.com>
> Pager: 805-286-8331
> Fax: 805-250-8315
> Home: 805-250-8315
> Netscape Conference Address
> Additional Information:
> Last Name Hauber
> First Name Thomas
> Version 2.1
--
\begindata{text,543267208}
\textdsversion{12}
\template{messages}
Rodney A Johnson\bold{, } \
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.\
\enddata{text,543267208}
Rodney Johnson
known). This protocol requires that the whole file be transformed prior to
sending to the printer (unless the printer servers step up to the revised RFC
1179). If there are ANY problems trying to send this file, we retry again.
This is due mostly to the unstableness of any given network. We were forced
to retry for just about anything due to the unpredictability of the
LPD server's responses. With the HP PJL driver support, the data is
transformed in smaller chunks and sent while the next chunk of data is being
transformed. The printer server receiving the data sends it through to the
printer and starts printing right away (as may LPD servers...but we don't
know that). We don't expect to receive problems sending the data (TCP layer
takes care of resending packets that get lost...up to some configuration
setting in TCP). If we loose the connection, we don't know if someone else
has obtained a connection and printed a file before we could reconnect, thus
having the possibility of the hard copy of the file being split one or more
times. If there were a lot of system printing to the same printer, and the
connections kept getting lost, the output bin of the printer would be a hodge
podge of paper. I really don't think you would be too thrilled about sorting
the printed output into the separate documents. Read my response to Thomas
Hauber. There is some configuration considerations you may want to check
out. You won't find this in any one manual.
Double Down wrote:
> I just converted my LAN printers from remote outq's to LAN printers. I am
> noticing the same issue. I am using IBM 4324's, and the appropriate
> drivers. The writers seem to drop for no reason at all.
>
> Thomas Hauber wrote in message <36DF011F...@iname.com>...
> >We recently acquired an HP 4000 that we can use on our NT network.
> >However when we print to it via IP from our AS400 (running V4R2), it
> >will end the writer abnormally after several pages have printed. We
> >have been unable to isolate the problem.
> >
> >Could this perhaps be a driver issue on our AS400? Below is the command
> >we used to create the *LAN printer device:
> >
> >CRTDEVPRT DEVD(CSLZ) DEVCLS(*LAN) TYPE(3812) MODEL(1) +
> > LANATTACH(*IP) PORT(9100) ATTACH(*DIRECT) +
> > ONLINE(*YES) FONT(11) FORMFEED(*AUTOCUT) +
> > PRTERRMSG(*INQ) MSGQ(QSYSOPR) +
> > TRANSFORM(*YES) MFRTYPMDL(*HP6) +
> > CHRID(*SYSVAL) +
> > RMTLOCNAME('192.168.100.30') +
> > SYSDRVPGM(*HPPJLDRV) TEXT('CSLZR *LAN +
> > printer description')
> >
> >We decided to use the MFRTYPMDL(*HP6), because there was no *HP4000.
> >Could this be the problem?
> >
> >Any help would be appreciated.
> >--
> >NOTICE TO BULK E-MAILERS: Pursuant to US Code, Title 47,
> >Chapter 5, Subchapter II, 227,
> >and all nonsolicited commercial e-mail
> >sent to this address is subject to a download and
> >archival fee in the amount of $500 US.
--
Mike
Spools will hang on the outq in a state of PND, the writer is started and
there are no MSG's waiting on either the DEVD or the WTR.
Mario Lemay
from the AS/400. I used the same command and parameters you used to create
the device but there is one difference :
I used MFRTYPMDL(*HP4) instead of MFRTYPMDL(*HP6).
Also, make sure you've got PARITY(*NONE), STOPBITS(1), ENVELOPE(*NONE), and
also don't forget to specify PPRSRC1 and 2.
Hope this helps,
Mario Lemay
IT Manager
Acton International Inc.
mle...@abacom.com
Thomas Hauber a écrit dans le message <36DF011F...@iname.com>...
Rodney Johnson
configuration tips. If a file stays in PND status, that is usually due to
one of two things. 1) the writer has been ended abnormally, and file
spooled file was left in the PND status (clean this up by calling program
QSPFIXUP) 2) the writer cannot get the proper response from the printer.
The second case I don't remember seeing with the HP PJL driver. I did see
it when using PSF/400 *IPDS *LAN attached printers. In that situation, it
turned out to be the printer was "offline". A good way to detect this
(other than going to the printer), is to look under the (via WRKACTJOB) QSPL
subsystem and see if the writer job is in SELW status. This indicates that
TCP/IP is timing out in its attempts to contact the printer.
Mike wrote:
> I am getting similar problems on several of our HP4000n's
> Spools will hang on the outq in a state of PND, the writer is started and
> there are no MSG's waiting on either the DEVD or the WTR.
>
> Thomas Hauber wrote in message <36DF011F...@iname.com>...
> >We recently acquired an HP 4000 that we can use on our NT network.
> >However when we print to it via IP from our AS400 (running V4R2), it
> >will end the writer abnormally after several pages have printed. We
> >have been unable to isolate the problem.
> >
> >Could this perhaps be a driver issue on our AS400? Below is the command
> >we used to create the *LAN printer device:
> >
> >CRTDEVPRT DEVD(CSLZ) DEVCLS(*LAN) TYPE(3812) MODEL(1) +
> > LANATTACH(*IP) PORT(9100) ATTACH(*DIRECT) +
> > ONLINE(*YES) FONT(11) FORMFEED(*AUTOCUT) +
> > PRTERRMSG(*INQ) MSGQ(QSYSOPR) +
> > TRANSFORM(*YES) MFRTYPMDL(*HP6) +
> > CHRID(*SYSVAL) +
> > RMTLOCNAME('192.168.100.30') +
> > SYSDRVPGM(*HPPJLDRV) TEXT('CSLZR *LAN +
> > printer description')
> >
> >We decided to use the MFRTYPMDL(*HP6), because there was no *HP4000.
> >Could this be the problem?
> >
> >Any help would be appreciated.
> >--
> >NOTICE TO BULK E-MAILERS: Pursuant to US Code, Title 47,
> >Chapter 5, Subchapter II, 227,
> >and all nonsolicited commercial e-mail
> >sent to this address is subject to a download and
> >archival fee in the amount of $500 US.
--
Thomas Hauber
for the *modem connection. Our printers are connected *direct via
ethernet.
Mario Lemay wrote:
>
> I've got 2 HP4000TN on my NT network and I'm using both of them to print
> from the AS/400. I used the same command and parameters you used to create
> the device but there is one difference :
> I used MFRTYPMDL(*HP4) instead of MFRTYPMDL(*HP6).
>
> Also, make sure you've got PARITY(*NONE), STOPBITS(1), ENVELOPE(*NONE), and
> also don't forget to specify PPRSRC1 and 2.
>
> Hope this helps,
>
> Mario Lemay
> IT Manager
> Acton International Inc.
> mle...@abacom.com
>
> Thomas Hauber a écrit dans le message <36DF011F...@iname.com>...
Thomas Hauber
of the HP4000's somewhat. They still on occasion end the writer
abnormally without explanation.
I am not certain that it is entirely a configuration issue. We have
been printing for several months via IP to a couple of HP4si printers
without these same problems that the HP4000s are giving me. Both myself
and the network administrator suspect the IBM HPPJLDRV may be at fault.
This also brings up another question, what role does the MFGTYPMDL
parameter play in all of this. As I mentioned in my previous message
there is no *HP4000 option, we had to fudge and use the *HP6. Someone
also suggested that I use the *HP4. Is this going to make a
difference? Is IBM going to provide an *HP4000 option to this
parameter?
Currently we are at V4R2, but this Saturday we will be going to V4R3.
Will that help, hurt or do nothing?
Thomas Hauber
startup job we start the writers for the HP4000's and they end with the
following joblog:
5769SS1 V4R2M0 980228 Job
Log S1042307 03/08/99 06:21:37
Page 1
Job name . . . . . . . . . . : CSLZ User . . . . . . :
QSPLJOB Number . . . . . . . . . . . : 059136
Job description . . . . . . : QSPLPRTW Library . . . . . :
QGPL
MSGID TYPE SEV DATE TIME FROM
PGM LIBRARY INST TO PGM LIBRARY INST
CPF1124 Information 00 03/08/99 03:13:15
QWTPIIPP QSYS 059D *EXT *N
Message . . . . : Job
059136/QSPLJOB/CSLZ started on 03/08/99 at 03:13:14 in
subsystem QSPL in QSYS. Job
entered system on 03/08/99 at 03:13:13.
*NONE Request 03/08/99 03:13:15
QWTSCSBJ *N QCMD QSYS 0154
Message . . . . : -CALL
QSYS/QSPWTRM1
*NONE Diagnostic 03/08/99 03:15:20
QWPPJLDR QSYS *STMT QWPPJLDR QSYS *STMT
From module . . . . . . . . :
WPPJLDR
From procedure . . . . . . :
Examine_BiDi
Statement . . . . . . . . . : 78
To module . . . . . . . . . :
WPPJLDR
To procedure . . . . . . . :
_C_pep
Statement . . . . . . . . . : *N
Message . . . . : Parsing PJL:
Missing FormFeed
*NONE Diagnostic 03/08/99 06:19:48
QWPPJLDR QSYS *STMT QWPPJLDR QSYS *STMT
From module . . . . . . . . :
WPPJLDR
From procedure . . . . . . :
Examine_BiDi
Statement . . . . . . . . . : 78
To module . . . . . . . . . :
WPPJLDR
To procedure . . . . . . . :
_C_pep
Statement . . . . . . . . . : *N
Message . . . . : Parsing PJL:
Missing FormFeed
CPD338D Diagnostic 40 03/08/99 06:21:36
QWPPJLDR QSYS *STMT QWPPJLDR QSYS *STMT
From module . . . . . . . . :
WPPJLDR
From procedure . . . . . . :
Socket_Recv
Statement . . . . . . . . . : 41
To module . . . . . . . . . :
WPPJLDR
To procedure . . . . . . . :
_C_pep
Statement . . . . . . . . . : *N
Message . . . . : An error
occurred while receiving data.
Cause . . . . . : A
communications error occurred while receiving data from
remote device at RMTLOCNAME
192.168.100.35. The error code is 3426. This
error can also occur when the
system attempts to print to the remote device
after it has been powered off and
on while the printer writer remains
active. Recovery . . . : Try
the request again. If the problem continues,
end TCP/IP using the End TCP/IP
(ENDTCP) command, start TCP/IP by using the
Start TCP/IP (STRTCP) command,
and then try the request again.
CPF3473 Escape 60 03/08/99 06:21:37
QSPOPNWX QSYS 00B2 QCMD QSYS 0180
Message . . . . : Writer
059136/QSPLJOB/CSLZ did not end normally.
Recovery . . . : See the
previously listed messages to determine cause of
the writer failure. Correct any
errors and start the writer again.
CPC2402 Completion 50 03/08/99 06:21:37
QCMD QSYS 056F *EXT *N
Message . . . . : Job ended.
Cancel message received at command processor.
Cause . . . . . : A message with
a severity equal to or exceeding the end
severity was received at the
command processor. Recovery . . . : See the
messages previously listed to
determine the message that caused the job to
be ended. Correct the errors, and
then try the request again.
CPC2191 Completion 00 03/08/99 06:21:37
QLIDLOBJ QSYS 03D0 QLICLLIB QSYS 028A
Message . . . . : Object
SPLAPISPJL in QTEMP type *USRSPC deleted.
CPC2191 Completion 00 03/08/99 06:21:37
QLIDLOBJ QSYS 03D0 QLICLLIB QSYS 028A
Message . . . . : Object
PJL_DRVRSP in QTEMP type *USRSPC deleted.
CPF1164 Completion 00 03/08/99 06:21:37
QWTMCEOJ QSYS 00A9 *EXT *N
Message . . . . : Job
059136/QSPLJOB/CSLZ ended on 03/08/99 at 06:21:37; 3
5769SS1 V4R2M0 980228 Job
Log S1042307 03/08/99 06:21:37
Page 2
Job name . . . . . . . . . . : CSLZ User . . . . . . :
QSPLJOB Number . . . . . . . . . . . : 059136
Job description . . . . . . : QSPLPRTW Library . . . . . :
QGPL
MSGID TYPE SEV DATE TIME FROM
PGM LIBRARY INST TO PGM LIBRARY INST
seconds used; end code 20 .
Cause . . . . . : Job
059136/QSPLJOB/CSLZ completed on 03/08/99 at 06:21:37
after it used 3 seconds
processing unit time. The job had ending code 20.
The job ended after 1 routing
steps with a secondary ending code of 0. The
job ending codes and their
meanings are as follows: 0 - The job completed
normally. 10 - The job completed
normally during controlled ending or
controlled subsystem ending. 20 -
The job exceeded end severity (ENDSEV job
attribute). 30 - The job ended
abnormally. 40 - The job ended before
becoming active. 50 - The job
ended while the job was active. 60 - The
subsystem ended abnormally while
the job was active. 70 - The system ended
abnormally while the job was
active. 80 - The job ended (ENDJOBABN command).
90 - The job was forced to end
after the time limit ended (ENDJOBABN
command). Recovery . . . : For
more information, see the Work Management
book, SC41-5306.
Rodney Johnson
we got back an error when trying to receive information from the printer. This
would indicate either a network or hardware problem. I'm not sure how you can say
that it's the HPPJLDRVR at fault when it works just find to the HP4Si printers.
The code is IDENTICAL for each case (from a communications standpoint).
As to the MFGTYPMDL, that has to do with how Host Print Transform transforms
various commands. For things like line feeds or form feeds (if I remember right),
you can specify a specific bytes string to be used to represent that function.
Generally speaking, you should be able to do the same thing as you would
configuring a printer on a PC. Pick a "driver" (in this case MFGTYPMDL) that best
matches your printer. As you go down the list, you start loosing function (gets
more general). The option to choose *HP4000 exists in V4R4.
As to upgrading to V4R3, I would suggest you get the latest and greatest PTFs for
module QWPPJLDR in QSYS. There may be some fixes that are NOT in the cum. pack.
Thomas Hauber wrote:
> I have tried some of your suggestions and have improved the performance
> of the HP4000's somewhat. They still on occasion end the writer
> abnormally without explanation.
>
> I am not certain that it is entirely a configuration issue. We have
> been printing for several months via IP to a couple of HP4si printers
> without these same problems that the HP4000s are giving me. Both myself
> and the network administrator suspect the IBM HPPJLDRV may be at fault.
>
> This also brings up another question, what role does the MFGTYPMDL
> parameter play in all of this. As I mentioned in my previous message
> there is no *HP4000 option, we had to fudge and use the *HP6. Someone
> also suggested that I use the *HP4. Is this going to make a
> difference? Is IBM going to provide an *HP4000 option to this
> parameter?
>
> Currently we are at V4R2, but this Saturday we will be going to V4R3.
> Will that help, hurt or do nothing?
>
--