vms lpd printing - jobs going to HOLD

[TMcB]

Hi

Our lpd print queues are behaving strangely.
When 2 jobs are sent in close succession, the first one prints OK, but the 2nd job sits on the generic queue at "holding" for 5 minutes time; instead of going to pending and printing immediately after the first one.

Is there anything I can do to make these jobs queue up and print immediately?

The only logicals I can see defined are :
"TCPIP$TELNETSYM_IDLE_TIMEOUT" = "0 00:00:15.00"
"TCPIP$TELNETSYM_RETRY_INTERVAL" = "0 00:00:10.00"

The queues were created using TCPIP$LPRSETUP, and have the following properties.

IST1$MAXPP|istba1$maxpp:\
:lf=/TCPIP$LPD_ROOT/000000/ISTBA1$MAXPP.LOG:\
:lp=IST1$MAXPP:\
:rm=t0532598\
:rp=text:\
:sd=/TCPIP$LPD_ROOT/ISTBA1$MAXPP08:

Each queue has a generic queue as well.

Generic printer queue MAXPP
/GENERIC=(IST1$MAXPP) /OWNER=[VAXSPM,SYSTEM] /PROTECTION=(S:M,O:D,G:R,W:S)

Server queue IST1$MAXPP, idle, on IST1::, mounted form DEFAULT
/BASE_PRIORITY=4 /DEFAULT=(FEED,FORM=DEFAULT) Lowercase /OWNER=[VAXSPM,SYSTEM] /PROCESSOR=TCPIP$LPD_SMB
/PROTECTION=(S:M,O:D,G:R,W:S) /RETAIN=ERROR

Thanks

[Karl Rohwedder]

5 minutes seems to be the default wait interval, if any error has occured.
Pls. have a look at the LPD section of the TCPIP management guide (e.g. http://h71000.www7.hp.com/doc/83final/6526/6526pro.HTML).
This seems to be configurable.

regards Kalle

[Jan van den Ende]

TMcB,

>>>
The only logicals I can see defined are :
"TCPIP$TELNETSYM_IDLE_TIMEOUT" = "0 00:00:15.00"
"TCPIP$TELNETSYM_RETRY_INTERVAL" = "0 00:00:10.00"
<<<

and

>>>
...
/PROCESSOR=TCPIP$LPD_SMB
<<<

It looks like you are confusing two disparate things!

The TCPIP$TELNETSYM logicals apply for queues that use /PROCESSOR=TLENETSYM.

Btw: in my view, TELNETSYM is by far the superior way do do IP printing from VMS!

fwiw

Proost.

Have one on me.

jpe

[TMcB]

Hi

I see now that the logicals are only referring the telnetsym queues.

The reason these queues were created using lpd was because they were going to a server name and a port named text ( rather than the usual ipaddress::9100.

is it possible to use telnetsym for servername::text?

Thanks

[Karl Rohwedder]

That depends, if the printer supports TELNET printing (many modern ones do) you may try TELNETSYM. Try a TELNET 'printer' to check, if the printer responds...

You may also try DCPS which supports many printer models.

regards Kalle

[Hoff]

As for alternate ports for telnet, yes. That's possible. See the print queue /ON="hostname:portnumber" mechanism -- details at http://h71000.www7.hp.com/doc/83final/6526/6526pro_055.html#telnet_print_chap

As for the stacked-up jobs and the delay, that's probably jobs colliding. Start by reading the log file ISTBA1$MAXPP.LOG. See what's there. Confirm it's a retry sequence.

The following text is from Ask The Wizard (ATW) topic 1020 -- yes, I know what's posted in that area in some detail :-) -- the ATW URL is http://www.hp.com/go/openvms/wizard -- and there's a whole bunch more IP printing and print troubleshooting information there -- has the following text:

...
TCP/IP Services Logical names:

Related logical names -- covered in the TCP/IP Services documentation in rather more detail -- can include (on releases prior to TCP/IP Services V5.0) UCX$TELNETSYM_IDLE_TIMEOUT, UCX$TELNETSYM_RAW_TCP, and UCX$TELNETSYM_SUPPRESS_FORMFEEDS. Alternatively, see the documentation for TCPIP$TELNETSYP_IDLE_TIMEOUT, TCPIP$TELNETSYM_RAW_TCP, and TCPIP$TELNETSYM_SUPPRESS_FORMFEEDS on TCP/IP Services V5.0 and later.

Messages such as "open_socket_ast invoked with bad IOSB 660: connect
to network object rejected." in the log file can be triggered by a
retry interval that is too short for the particular printer -- faster
printers can use shorter intervals, though faster polling can also
increase host overhead. (Values such as 15 to 30 seconds can be
appropriate for many printers.) To tell TCP/IP Services LPD to retry
the print job every minute:

$ DEFINE/SYSTEM/EXECUTIVE UCX$LPD_RETRY_INTERVAL "0 00:01:00.00"
$ DEFINE/SYSTEM/EXECUTIVE TCPIP$LPD_RETRY_INTERVAL "0 00:01:00.00"

In particular, you may also need to define one (or more) of
the following logical names:

$ DEFINE/SYSTEM/EXECUTIVE UCX$TELNETSYM_RAW_TCP 1
$ DEFINE/SYSTEM/EXECUTIVE TCPIP$TELNETSYM_RAW_TCP 1

$ DEFINE/SYSTEM/EXECUTIVE UCX$TELNETSYM_SUPPRESS_FORMFEEDS 1
$ DEFINE/SYSTEM/EXECUTIVE TCPIP$TELNETSYM_SUPPRESS_FORMFEEDS 1

$ DEFINE/SYSTEM/EXECUTIVE UCX$TELNETSYM_IDLE_TIMEOUT "0 00:00:30.0"
$ DEFINE/SYSTEM/EXECUTIVE TCPIP$TELNETSYM_IDLE_TIMEOUT "0 00:00:30.0"

Similar messages such as "open_socket_ast invoked with bad IOSB 556:
device timeout" can be triggered by device sharing, such as another
host system printing to the same printer. If the idle timeout setting
(or the equivilent mechanism on the other host) is set to a relatively
large value, the host with the long timeout can block this and other
hosts from accessing the printer. It is possible that the symbiont
within the printer itself has its own timeout setting or is otherwise
busy and is simply not responding sufficiently quickly. (Accordingly,
this IOSB 556 error can be benign, and you can silence the OPCOM
message using the NO_OPCOM logical name described below, or by by
adjusting the idle timeouts involved.) It is also possible that the
IOSB 556 device timeout error indicates a network problem, as this
error can also result from IP routing problems between the host and
the printer. (Use ping, and also try to telnet into the printer.)

Also consider the settings of the NO_OPCOM and LOG_KEEP logical names.
NO_OPCOM is a binary value, with 1 to disable OPCOM messages and 0 to
enable reception:

$ DEFINE/SYSTEM/EXECUTIVE UCX$TELNETSYM_NO_OPCOM 1
$ DEFINE/SYSTEM/EXECUTIVE TCPIP$TELNETSYM_NO_OPCOM 1

LOG_KEEP is set to the number of log files to retain:

$ DEFINE/SYSTEM/EXECUTIVE UCX$TELNETSYM_LOG_KEEP 9
$ DEFINE/SYSTEM/EXECUTIVE TCPIP$TELNETSYM_LOG_KEEP 9

Check your TCP/IP Services documentation for further details.
...


Stephen Hoffman
HoffmanLabs

[TMcB]

Thanks for getting back to me :

when I try to set up the queue using telnetsym I get an error message :
> init/queue/on="t0532598:text" testpp08 /proc=tcpip$telnetsym
> start/queue testpp08
%SYSTEM-F-IVDEVNAM, invalid device name

It doesnt seem to like sending to a port called 'text'

The log files mention :
TCPIP LPD configuration data:
LPD Spooler Directory : TCPIP$LPD_ROOT:[000000]
Retry-Interval : 0 00:05:00.00
Retry-Maximum : 0 01:00:00.00
Idle-Timeout : 0 00:05:00.00

Is it possible to change these retries?

Some of the log files mention :
%TCPIP-E-LPD_REQREJECT, print request rejected by t0532598 (queue text)
Which I guess is when is puts the jobs on hold for 5 minutes to retry.

Thanks

[Hoff]

Um, "text" isn't an IP port number. (It might be interesting to have telnetsym tied into a portmapper running inside the printer and to have this resolve the port number dynamically, but I can't say I've seen that implemented anywhere before. But I digress.) Specify the numeric port for the printer port.

>> Is it possible to change these retries?

Yes. Redefine the logical names.

And yes, the rejection messages in the log can be the signature of the backoff and retry sequence; of a collision. In this case, that's one of the errors I'd expect to see.

And yes, you can speed up the retries to speed up the printing when collisions arise. This involves locating where the logical names are set in your startup (assuming you're not depending on the defaults set by TCP/IP Services itself) and establish the new values in your local system startup.

I'd probably use SYSTARTUP_VMS.COM to house the local (re)definitions, and keep it all in close proximity to the queue and the TCP/IP processing.

HoffmanLabs can set up and can manage IP and IP printing for you and can help with OpenVMS and related troubleshooting, as well.

[Jan van den Ende]

TMcB,

the port you specify for TELNETSYM should be the (numeric !) port on which the printer expects TELNET control connections.
They can vary, but the ones I know are all 9100 (HP, Nahuatec, and Kyocera).

hth,

Proost.

Have one on me.

jpe

[TMcB]

thanks - the printer is a barcode printer and the manufacturer's documentation only refers to the port as'text'.

I'' keep it as an LPD printer instead and try the tcpip$lpd logicals to see if I can get the retry time down

Your replies are very much appreciated