Printer via Print server with tcp/ip

[Edgar Ulloa]

Hi
I have a ovms 8.3 integrity server.
I was creating a queue acceso

Printer queue acceso, idle, on Norus1::"acceso:9100", mounted form DEFAULT
/BASE_PRIORITY=4 /DEFAULT=(FEED,FORM=DEFAULT) Lowercase /OWNER=[PLAN,*]
/PROCESSOR=TCPIP$TELNETSYM /PROTECTION=(S:M,O:D,G:R,W:S)

I have ping continuos at this queue.

when the user send 2 jobs o more, the system sent this jobs to print server inmediatly.

the queue turns to Stalled.
Probably because print server don't have enought memory for keep more two jobs.

the jobs it lose when the users reset the print server without start the queue.

Some one knows how I can fix the issue for not have more stalled when send two o more jobs..?

Assign Memory in tcp/ip..?
Any command that dont send the job to the print server if this is busy..?

Thanks for your comments

[labadie_1]

just do
$ reply/enable=printer
throw your 2 jobs to the printer, and post the messages that display on your terminal.

[EdgarZamora]

It might also help to know what kind of printer you are using (make and model) and also the command line you used to initialize your queue. Are you using DCPS (you mentioned printserver but I'm not sure if you are referring to DPCS or the "network" card)?

[Hakan Zanderau ( Anders]

The "stalled" state is a normal behavior for a queue running TCPIP$TELNETSYM.

Without the logical TCPIP$TELNETSYM_IDLE_TIMEOUT the queue will disconnect the link and try to connect again when starting then next job in the queue.

regards,

Hakan Zanderau
HA-solutions

[Edgar Ulloa]

The printers are
Tally 6212 and tally 6215
the queues are equals
I don't have the logical TCPIP$TELNETSYM_IDLE_TIMEOUT defined.

But the estalled is inmediatly after was sending the second big job.

The first job finish but the second one are stalled.

Thanks

[Jan van den Ende]

@Hakan,

>>>
The "stalled" state is a normal behavior for a queue running TCPIP$TELNETSYM.
<<<

Hardly. 100's of queues running TCPIP$TELNETSYM; but Stalled means something like paper-out, or (physical-) printer powered-down, or paper-jam, or...; whatever, but the printer hardware is NOT accepting printjobs.

This on various types of HP; Kyocera, and Nashua printers, all with ethernet connections, all via IP protocol (and in a former life, with LAT protocol as well)

fwiw.

Proost.

Have one on me.

jpe

fwiw

[Hakan Zanderau ( Anders]

Jan,

I used to support all the symbionts when I worked at the VMS Support Team at Digital/Compaq/HP.

Here some extracts from my (old) documentation:

Print queue frequently in "stalled" state:

When you print a job to a Telnetsym queue and it doesn't already have a link
to the printer it needs to establish one before it can print the job. In
cases where there is high contention for the printer there is a good chance
that the printer is occupied and that the link establishment will fail the
first time around. This will cause Telnetsym to keep trying to establish a
link periodically according to the retry interval logical. (See sections on
configuration of Telnetsym and on link establishment for more information.)
When the Telnetsym is waiting to establish the link the execution queue will
eventually go into a "stalled" state. When the link does come up the job will
be printed. A Telnetsym queue in the stalled state is not necessarily an
error.

If the queue goes stalled in the middle of a print job chances are the
printer is out of paper.


UCX$TELNETSYM_IDLE_TIMEOUT -
This logical defines the length of time after which Telnetsym is to terminate
an inactive link. The value for this logical is a VMS delta time. If this
logical is defined then Telnetsym will disconnect the link only when a period
of inactivity on the link equal to the time specified has passed. If this
logical is not defined then Telnetsym will release the link immediately after
the completion of each print job. For example, to define a link idle timeout
of ten minutes do:

$ DEFIN/SYS UCX$TELNETSYM_IDLE_TIMEOUT "0 00:10:00.00"

regards,

Hakan Zanderau
HA-solutions

I'm backing down from this case

[Hoff]

The Tally T6212 and Tally T6215 dot-matrix printers look to be typical network-based printers.

Seeing a network printer listed as stalled is normal and expected for telnetsym printing.

In addition to the various out-of-paper errors and other such triggers mentioned earlier, the stalled state can (also) point to access contention.

Typical settings for telnetsym aimed at the raw port (9100) are:

$ DEFINE /SYSTEM /EXECUTIVE TCPIP$TELNETSYM_RAW_TCP 1

$ DEFINE /SYSTEM TCPIP$TELNETSYM_RETRY_INTERVAL "0 00:00:30"

$ DEFINE /SYSTEM TCPIP$TELNETSYM_IDLE_TIMEOUT "0 00:01:00"

Circa TCP/IP Services V5.1 and later, see the TCPIP$TELNETSYM_SYSTARTUP.COM site-specific procedure for customizations.

Users resetting a printer and the resulting lost print jobs tends to be a self-correcting problem. That, or indicative of the need for a sticker near the power switch listing "press to eat print jobs" or some such.

You might also ring up TallyGenicom support, as (given the Genicom side of the house had some familiarity with DIGITAL printers) they may well have specific recommendations here.

[Hakan Zanderau ( Anders]

Thanks Hoff !

[Edgar Ulloa]

I was set this logicals but looks like does not work.

Printer queue LTA120, busy, on YIRE2::"lta120:9100", mounted form DEFAULT

Entry Jobname Username Blocks Status
----- ------- -------- ------ ------
660 PMCLOS ICORDOBA 15 Printing
663 EMPALP ICORDOBA 21 Pending
661 DEERPT ICORDOBA 31 Pending

---------------------------------
when change to execute entry 663 inmediatly stalled.
the paper is continous, the printer is idle and ping is continuos also.


------------------
Printer queue LTA120, stalled, on YIRE2::"lta120:9100", mounted form DEFAULT

Entry Jobname Username Blocks Status
----- ------- -------- ------ ------
663 EMPALP ICORDOBA 21 Stalled

[Jan van den Ende]

Hakan,

I stand corrected.

Obviously one of the effects of so many printers must have been that contention was rare.

Proost.

Have one on me.

jpe

[Bill Hall]

Edgar,

My first thought on reading your post was that you have an asynchronous communication problem, probably the handshaking. Are you using a network print server connected to the printer's serial port or parallel port such as one of the HP Jetdirect servers?

Bill

[Edgar Ulloa]

Hi
The print server is a internal card of tally printers.

another one is conected a print server hpjetdirect 300x with same efects.

I will try to regenerate the queue completly and try again.
regards

[Edgar Ulloa]

Labadie ask me about reply/ena=printer

this message show me continue

TCPIP$TELNETSYM - (planta) open_socket_ast invoked with bad IOSB 556: device time out

[Hakan Zanderau ( Anders]

Edgar,

You have to tell me the whole story.......

It worked/works when.....
and when we...... it fails.

Have the printers/queues ever worked as expected ?

I have a lot of other questions, but let's start here.

One thing about the logicals....
The logicals are red at image activation ( start of the queue ).
You can't define a logical name without restarting the queue ( killing the symbiont process ) and the logicals are used during the lifetime of the symbiont process.

Now we are talking about logicals for TELNETSYM. ( to avoid any remarks )

regards,

Hakan Zanderau
HA-solutions

[Jan van den Ende]

Edgar,

>>>
Printer queue LTA120, busy, on YIRE2::"lta120:9100",
<<<
combined with
>>>
TCPIP$TELNETSYM - (planta) open_socket_ast invoked with bad IOSB 556: device time out
<<<

leads to the question:

What is the result of NSLOOKUP LTA120 , if executed from YIRE2 ?
(if it not already exists, first create a foreign command symbol
$ nslookup :== $ TCPIP$NSLOOKUP
)
If this gives a result, and the result is the correct IP address, try PING LTA120
If NSLOOKUP fails, then check your name resolution. (do you use DNS or TCPIP$HOSTS? ;
How is your DNS defined? And the ROUTING?

The open_socket_ast is usually a sign of unrecognised queue address.

Proost.

Have one on me.

jpe

[junaid akhtar]

As we are using Integrity Rx3600 and VMS 8.3
and we are printing through 3com switch on PRINTRONICX printer using tcpip.here is the command we are using .it may help you
Make a file name TCPIP_QUEUS.COM
and put the following command in it
$ init /queue (logical name of printer) /process=tcpip$telnetsym /start /default=(nofeed,flag) /on=node name::"ip address of printer:9100"
put this file in startup file.

[Hakan Zanderau ( Anders]

Edgar,

Sorry, but I'm leaving this thread.

[Hakan Zanderau ( Anders]

Sorry Edgar, but I can't leave this without

Jan, have you EVER tried starting a TELNET-queue using a NON-existing hostname ?

$ INIT/QUE/START/PROC=TCPIP$TELNETSYM/ON="IDONTEXIST:9100" TEST
%SYSTEM-F-IVDEVNAM, invalid device name

regards,

Hakan Zanderau
HA-solutions

[Jan van den Ende]

Hakan,

>>>
Jan, have you EVER tried starting a TELNET-queue using a NON-existing hostname ?
<<<

Yes. I know that.

-Have you ever started a queue succesfully on on node, and then failed over to a node that did NOT have the correct name resolution?
-Have you ever had a printer (relocated and) given an other IP address WITHOUT informing VMS management?
-Have you ever have the network people reconfigure some subnet without telling you?
(-and have you ever had a printer removed, without the users realising that the printer they have "always" used is now gone?

All these generate
open_socket_ast
and if:
your printers are spread up to 100KM away; your network people are a different group, located in a different building;
your periferal device handling department is a different group again, which ONLY understans M$, and are incapable of understanding WHY they should report changes in periferal configs to others than the M$ admins,
THEN you get used to "open_socket_ast", on average at least one new one each week.

fwiw.

Proost.

Have one on me.

jpe

[Edgar Ulloa]

No problem frinds
I will try to do all your recomendations probably I will be able to start the queues via decnet and try again.

[Edgar Ulloa]

It works now
That was the solution

I made a generic queue
into ucx put aliases at same ip address
queue1, queue2
I made the generic queue the jobs was sending at generic and now is no more stalled.

Thanks all for your coments

[Edgar Ulloa]

Thanks for your help and comments