Problems printing to a terminal server printer

[Raymond P. Manyik]

We are having problems printing to a DECLASER 3500 (postscript printer) connected to a DECserver 200. The system is configured to communicate with 4 computers, 2 DEC4000/705A's VMS 6.1 and 2 DS20Es running Open VMS 7.1-2. We are using TSM on the VAXs to configure the DECserver 200 and all communication to the TSM is done with DECNET IV.

The print queue is set up as a LAT port (LTA24)
And a logical name is defined
Define/group periodic lta24

With all other periodic queues stopped on three of the machines a series of print jobs was printed successfully. Then a new series of jobs was demanded.

> print/queue=periodic NNN.OUT
Job NNN (queue LTA24, entry 158) pending
pending status caused by queue stopped state

> show queue/dev/all periodic
Printer queue LTA24, stopped, on NODE2::LTA24:, mounted form LN14_DEFAULT
(stock=DEFAULT)

Entry Jobname Username Blocks Status
----- ------- -------- ------ ------
153 LIVEM05
USER05 5 Pending

Using the START/QUE LTA24 and
START/QUE PERIODIC
Commands do not result in a started the queue. LTA24 remains in a stopped state.

This failure to print is complicated when all 4 machines have active queues.

The Terminal Server has been changed out with a known good TS. The TS setup for the terminal server was downloaded using TSM and an existing server setup command file. This setup was compared to a working server with the same setup without noting any differences.

Any ideas?

[Arch_Muthiah]

Raymond,

Go thru this thread, may be usefull...

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=973770

[Raymond P. Manyik]

Going thru the previous thread I found////// What causes the Active port state and connected link LAT$LINK?

[NOT WORKING]
Local Port Name: _LTA24: Local Port Type: Application
(Queued)
Local Port State: Active
Connected Link: LAT$LINK

Target Port Name: PERIODIC Actual Port Name: PERIODIC
Target Node Name: CR2 Actual Node Name: CR2
Target Service Name: Actual Service Name:

=======================================================================
[WORKING]
Local Port Name: _LTA14: Local Port Type: Application
(Queued)
Local Port State: Inactive
Connected Link:

Target Port Name: PERIODIC Actual Port Name:
Target Node Name: CR1 Actual Node Name:
Target Service Name: Actual Service Name:
=======================================================================
[WORKING]
Local Port Name: _LTA56: Local Port Type: Application
(Queued)
Local Port State: Inactive
Connected Link:

Target Port Name: TESTPOSTSCRIPT Actual Port Name:
Target Node Name: DS5 Actual Node Name:
Target Service Name: Actual Service Name:

========================================================================
=
Continuing on thru threadid=973770

We use DCPS$SMB for the symbiont/ not LATSYM. Could this be causing
the problem?

We had already used this thread to set
LATCP> set node/connection=both
In the startup files.

[Michael Yu_3]

Hi Raymond,

From the LATCP show port output of the port which is not working, it shows that the port was actually ACTIVE with an EXISTING connection.

The reason why you could not start queue was that the port on the DECserver still had a connection active.

DCPS actually disconnects from LAT ports at the end of a job, provided the printer sends a CTRL/D character back to the host at job's end. Otherwise, it will hold on to the LAT port without releasing it.

Please check the state of the queue on the node which you printed successfully. If it is idle, then it should have released the LAT port.

BTW, which version of DCPS are you using?

Thanks and regards.

Michael




Thanks and regards.

Michael

[Raymond P. Manyik]

Thanks for the insights. We keep getting closer, but are not at an acceptable level yet. We went from being able to print one or two jobs to about a dozen, and with your inputs, we are into the low 10s of jobs (~40 or so) before the queues hang.

With regard to Michael's question, how do you display the version of DCPS?

Based on the DCPS information supplied by the Forum answer I did some searching and found
SYS$COMMON:[000000.SYSHLP.EXAMPLES.DCPS]DCPS$DS200-PORT-SETTINGS.COM

This file has some settings that do not appear when performing:

TSM_SVR_CR2> show port n char

There are additional server setup examples in that location that may be helpful to others. ========================================================================

SYS$COMMON:[000000.SYSHLP.EXAMPLES.DCPS]DCPS$DS200-PORT-SETTINGS.COM

Items not already setup.as part of our server setup files.

set port 'p1' dialup dis [DISABLED is Default - performed these commands to assure settings] def port 'p1' dialup dis

If a port user has a dial-in modem, DIALUP allows the server to communicate this to a service node. The service node may use this information for security purposes. DIALUP {ENABLED }
{DISABLED} *
ENABLED means that the server notifies service nodes about the dial-in modem. DISABLED means that the server indicates the port device is not a dial-in device. !! set port 'p1' DTRwait dis [performed these commands to assure settings] def port 'p1' DTRwait dis

[DTRWAIT determines if the DECserver asserts certain modem signals when a port
is inactive. Normally, DTRWAIT should be ENABLED for remote access
ports.
DTRWAIT {ENABLED }
{DISABLED} *
ENABLED causes a delay in asserting DTR and RTS until the server detects RI from a modem or until a remote connection is made at the port. DISABLED means the server asserts DTR and RTS signals when idle.]

!!
set port 'p1' multisession dis (HELP says DISABLED is default) def port 'p1' multisession dis

!!
set port 'p1' queuing en
def port 'p1' queuing en
(CHANGED TO :ENABLED - this is a different setting from our working
unit)

QUEUING allows the port's connection requests to be placed in a queue on the
server that offers the service. That server queues a request
when: (1) a
requested service is set up to accept queued requests, (2) the service cannot immediately handle new sessions. QUEUING {ENABLED }
{DISABLED} *
ENABLED means that placing connection requests in server queues is attempted. DISABLED means that connection requests are not queued.

!!
set server queue limit 24
def server queue limit 24
(CHANGED TO :24 - this is a different setting from our working unit which had "none")

QUEUE LIMIT sets up the maximum number of host-initiated request entries permitted in the DECserver connection queue.

Following change of settings

TSM>TRIGGER SERVER CR2

To remotely reboot.
========================================================================
==============================

This appeared to help things, but still did not result in reliable interleaving of jobs without stopping and resetting queues.

A recheck of Hardware/Firmware settings on the DEC3500 resulted in noticing that
Interface settings:
Parallel: Enabled: PS/PCL Sensing
Serial: Enabled: PS/PCL Sensing (changed from BCP postscript)
Xon/Xoff, 9600 (Changed fromRobust Xon/Xoff, 9600)

We believe that the PS/PCL Sensing setting on the printer probably is the smoking gun. What is your opinion?

[Lawrence Czlapinski]

Raymond: It sounds like you have 4 non-clustered systems trying to print to the queue LTA24.
1. Make sure LTA24 is defined on the system. Since you get some printouts from this system it must be defined.
2. In LATCP, the CREATE command should have /QUEUE.
3. When printing from multiple systems, it is helpful to have the LAT device
$SET DEVICE/SPOOL LTAxxx
or
$SET DEVICE/SPOOL logical_device_name (such as PERIODIC_DEVICE
4. We use /PROCESSOR=LATSYM.
5. It might be the symbiont hanging. Do a SHOW LOG/SYS LAT$SYMPARAMETER.
You could trying lowering the number of printers on each symbiont to see if it helps.
On some systems we had to do this because a printer would stop printing and couldn't be restarted. The symbiont would appear to hang.
Normally each symbiont has multiple printers. It could be another printer on that symbiont is contributing to the problems.
$ SHOW DEV LTA24:/FULL ! to get the symbiont name and process id.
Do a show proc/id/all to list the devices using the same symbiont as LTA24.
$ sh proc/id=symbiont_process_id

7-DEC-2005 17:42:13.34 User: SYSTEM Process ID: 2020012F
Node: ASDEV1 Process name: "SYMBIONT_5"

Terminal:
User Identifier: [SYSTEM]
Base priority: 4
Default file spec: Not available
Number of Kthreads: 1

Devices allocated: ASDEV1$LTA234:
ASDEV1$LTA3125:
ASDEV1$LTA3137:
ASDEV1$LTA4142:
6. You could
$ stop/queue/reset LTA24
$ delete/queue LTA24
$! then recreate the queue which should put it in a different symbiont.
Lawrence

[Lawrence Czlapinski]

$ set device/spool=(queue_name,sys$disk) lta24: !note sys$disk is the current default disk for the user that is setting the device.
Using a queue name the same as the device name can be confusing.
We use queuename_device logicals for our device names. You don't have to do it that way. An advantage is that if we have to switch to create a temporary LTA number because an LTA gets temporarily hung, the queue will use the new LTA number. We use the convention of LTA9xxx for temporary numbers.
Lawrence

[Michael Yu_3]

Hi Raymond,

Just perform the following and check for the latest version of DCPS.

$ dir sys$help:*DCPS*.release_notes

Thanks and regards.

Michael