Print job not working with the new printer server (windows 2000R2)

[Navipa]

Dear,

We use DEC TCP/IP Services for OpenVMS VAX Version V3.2
on a VAX 4000-50 running OpenVMS V6.1.

We had win2003 as a printer server; all the queues and printers were working properily since many years until we recently changed the old printer server with the new printer server (windows 2008R2).

with the new print server, the jobs were not getting queued and nothing gets printed. new printer server's IP is added to ucx$host file. I could able to ping.

I tried creating new print queue,tested with the following command

$ init/queue/start /owner=[1,4] /retain=error /device=server /process=ucx$lpd_smb /prot=(s:e,g:r,w:w,o:d) testprn and no other changes done to any other DCL scripts, but the "$print/queue=queuename filename", does not work. when I run "LPQ TESTPRN", I get "%UCX-E-LPQ_LOSTCONNTO, lost connection to host xxhostnamexxx"

$SHOW QUE/Full

Server queue testprn, idle, on node1::, mounted form DEFAULT

  /BASE_PRIORITY=4 /DEFAULT=(FEED,FORM=DEFAULT) /OWNER=[SYSTEM]

  /PROCESSOR=UCX$LPD_SMB /PROTECTION=(S:M,O:D,G:R,W:S) /RETAIN=ERROR

Server queue UCX$LPD_QUEUE, idle, on node1::, mounted form DEFAULT

  /BASE_PRIORITY=4 /DEFAULT=(FEED,FORM=DEFAULT) /NOENABLE_GENERIC

  /OWNER=[SYSTEM] /PROCESSOR=UCX$LPD_SMB /PROTECTION=(S:M,O:D,G:R,W:S)

  /RETAIN=ERROR

LATCP> show node/full

Node Name:   node1                         LAT Protocol Version:      5.2

Node State:  On

Node Ident:  .Welcome to VAX/VMS V6.1

Incoming Connections:  Enabled              Incoming Session Limit:   None

Outgoing Connections:  Disabled             Outgoing Session Limit:   None

Service Responder:     Disabled

Can please give some idea please. do I need to change any other DCL scripts, and restart any  service?  

Thanks

Navipa

[Steven Schweda]

> [...] /process=ucx$lpd_smb [...]

   Ok.  You want to use LPD/LPR.  Is there an LPD server running on your
"windows 2008R2" system?

      telnet /port = 515 xxhostnamexxx

   What's in your SYS$SPECIFIC:[UCX_LPD]UCX$PRINTCAP.DAT file?

   Have you tried reading some (not-error-free) documentation?  For
example:

http://h30266.www3.hp.com/odl/vax/network/tcpipv42/manage/6526pro_015.html#part_5_

[abrsvc]

There are a few ways to address this:

1) Check the differences between the printservers (2003 and 2008) and set up the new print server to mimic the behavior of the "old" one.   Let's face it, teh VMS siode didn't change here, the printserver side did.  Place the blame for hte current failure where it should be:  on the part that changed.

2) Try to better understnad hte failure here.  Is the connection failing?  If so, what is the failure?  Is there an update to the UPD proptocol that is not being handled by the VAX side? (Likely)

3) Upgrade the OpenVMS side to a supported version and call HP for assistance.  I think the oldest supported version is either V6.2 or V7.3?

To try to get more information, perhaps use a network tracer to see the actual packets and understand the connection problems.   There is really not enough info here to resolve this.

Dan

[Steven Schweda]

> [...] There is really not enough info here to resolve this.

   Well, duh.  (But compare this with the previous posting to see the
improvement.)  However, if no one has made any changes to the printcap
data, then it seems possible (likely?) that the "rm" and/or "rp" values
there are now obsolete, and such defects might explain the symptoms.


> [...] Place the blame for hte current failure where it should be:  on
> the part that changed.

   If the target moves, and the rifleman begins to miss it, whom should
we blame, the target or the rifleman?

[Navipa]

Big doubt steven...

LPD service runs in printer server

Telnet using 515

LPD listens

Service Port Proto Process Address State
LPD 515 TCP UCX$LPD 0.0.0.0 Enabled

But initialize the queue in UCX$LPD_STARTUP.COM using /proce=ucx$lpd_smb  ---> is it ok?

-------------------------------------------------------

$ ucx sh serv lpd/full

Service: LPD
State: Enabled
Port: 515 Protocol: TCP Address: 0.0.0.0
Inactivity: 5 User_name: UCX_LPD Process: UCX$LPD
Limit: 5 Active: 0 Peak: 0

File: SYS$SPECIFIC:[UCX_LPD]UCX$LPD_RCV_STARTUP.COM
Flags: Aprox Listen

Socket Opts: Rcheck Scheck
Receive: 0 Send: 0

Log Opts: Acpt Actv Dactv Conn Error Exit Logi Logo Mdfy Rjct TimO Addr
File: SYS$SPECIFIC:[UCX_LPD]UCX$LPD_RCV_STARTUP.LOG

Security
Reject msg: not defined
Accept host: 0.0.0.0
Accept netw: 0.0.0.0

------------------------------------
UCX$PRINTCAP.DAT file

#
# LOCAL PRINTERS
#
UCX$LPD_QUEUE:\
:lp=UCX$LPD_QUEUE:\
:sd=UCX$LPD_SPOOL:
LP|LP_00|lp|daffy:\
:lf=/R7WDEB$DIA0/SYS0/UCX_LPD/LP.log:\
:lp=sys$print:\
:rm=microvaxii:\
:rp=sys$print:\
:sd=/R7WDEB$DIA0/SYS0/UCX_LPD/LP:
#
LP2|LP2_00|lp2|STEVE:\
:lf=/R7WDEB$DIA0/SYS0/UCX_LPD/LP2.log:\
:lp=donald:\
:sd=/R7WDEB$DIA0/SYS0/UCX_LPD/LP2:
#
TSTPRN|testprn|testprn|Test Printer prnsvr1:\
:lf=/SYS$SPECIFIC/UCX_LPD/TESTPRN.LOG:\
:lp=TSTPRN:\
:rm=prnsvr1:\
:rp=testprn:\
:sd=/SYS$SPECIFIC/UCX_LPD/TESTPRN:
#

[Steven Schweda]

> LPD service runs in printer server
> Telnet using 515
> LPD listens

   As usual, showing actual commands with their actual output can be
more helpful than vague descriptions or interpretations.  With my weak
psychic powers, I can't tell if you're testing the LPD on the VAX or on
the Windows system.

> But initialize the queue in UCX$LPD_STARTUP.COM using
> /proce=ucx$lpd_smb  ---> is it ok?

   Which "the queue"?  I don't know if you care about LPD on the VAX.  I
thought that you were trying to use LPR (the client) on the VAX to talk
to an LPD (the server) on the Windows system.  If so, then who cares if
you also run LPD on the VAX?  (Do you have any local printers on the
VAX, or are the printers connected to the Windows system?)

> $ ucx sh serv lpd/full

   Why do we care about LPD on the VAX?

> UCX$PRINTCAP.DAT file

   Ok.

> :rm=microvaxii:\

   Again, with my weak psychic powers, I don't know who "microvaxii" is.

> :rm=prnsvr1:\

   Is that the Windows system?  (The new one or the old one?)

> :rp=testprn:\

   Is that the name of a printer (LPD printer service?) on the Windows
system?

   I also know nothing about the configuration of your Windows system,
or of LPD on your Windows system.

[MarkOfAus]

The "obvious" place to start is on Windows server.

I don't know anything about these but you need to see if, using the LPD on Windows server, you can print. Dah?

Is there a tool like lpr or lp available on windows to test print?

For example, lpr -P your_test_printer_name print_job.txt

If this can be accomplished on the windows server, then the problem is:

1. Firewall issue between Vax and Windows,

2. LPD is non-compliant and will never work (it's Microsoft after all so anything's possible)

3. The VAX server queues have a problem.

For point 3, can you create a server queue with the rm= portion set to the IP number of the printer you are testing on?

[Hoff]

Your available options, in no particular order.

• Downgrade the Microsoft Windows Server box back to the formerly-working configuration, and re-test with that.
• Replace the Microsoft box with an HP JetDirect or analogous device as host-based printing has been a compatibility problem for eons, and re-test with that.  This is usually the easiest and most reliable approach, and JetDirect and analogous devices are cheap and ubiquitous.
• Upgrade VMS to something more current, and re-test with that.   V6.1 is over twenty years old.   Much has changed since then.  Older software cannot be expected to be compatible with newer configurations.
• Commence detailed troubleshooting of the errant configuration.  This involves the details of the new configuration and the basic operations of the remote printing scheme, verifying DNS translations and all other network details of the printing configuration. and comparing the new setup with the previous and functional configuration, and quite possibly capturing the network traffic and looking for differences.   This troubleshooting probably won't happen here, as folks here don't have access to the configuration.

I'd also get going replacing that VAX with either emulation or with replacement hardware, but that's another discussion.  Yes, I've heard many folks claim their current hardware and software configurations cannot be upgraded.   Feel free to present your specific reasons that preclude such upgrades, but — from long experience in this business — once management decides to perform the software or server upgrade or to migrate to the replacement configuration, all those utterly impossible upgrades generally seem to start happening.

You'll also want to get a formal escalation path for gaining support for your endeavors, if you're going to continue to try to run this ancient hardware and software in your environment.   This particularly because there are many things that can go wrong with VMS, beyond the current discussions of printer compatibility issues.

[Navipa · Accepted solution]

All,

After a big struggle, I find some clue. Sorry I could not able to provide all the necessary details to you all. In fact I don't know many of the system config details even today. Anyway I have used ucx$lprsetup program and resolved the issue.

Thanks to Steven, abrsvc, markofAus and Hoff for your time.

Navipa.