Printer does not work anymore

[Rene Stanger]

Hello,

in a large IBM-Host, Unix and Windows environment we are running 3 Alpha OpenVMS Server. Now the IT is installing MFP's from Lanier instead of LAN printers. With DCPS Software we can use the LAN printers with tcpip connections. On a first try we could easily bring the new MFP to work properly. (officially not supported by DCPS, but with another MFP profile it's ok)
Shortly before going into production the MFP is no longer responding. It does not signal if it's ready to print, if I send a job, sometimes it will print, but my queue is hanging (printing...) and the MFP ist also blocking any other work, until I stop the queue on OpenVMS.

The Network people said they "only" changed the switches to autosensing, but they likely forget us OpenVMS people. The old LAN printers still work perfectly! From Windows the MFP work as expected.

Any ideas where the problem can be? I don't want our OpenVMS system be the only system that can't print on these MFP!

Regards
René

[Karl Rohwedder]

Are you using RawTCP or LPD for printing?

Often LPD works, whereas RawTCP makes problems, because LPD just copies the files to the printer.

regards Kalle

[Rene Stanger]

We are using RawTCPIP, but after the MFP didn't work anymore, I tried also a queue with LPD, my queue sent the file but the MFP didn't print anything, I just saw a status of "job aborted". With a standard synchronised RawTCP queue, the job remains starting.... With the logical nosync set, the queue stays printing...

Rene

[Karl Rohwedder]

Did you use the spool-file option of LPD?

I experimented last week with some Ricoh printers, some printed using RawTCP others only with LPD, some lost their ability to interpret PS (seem you may NOT switch them off without shutdown...).

regards Kalle

[Art Wiens]

Try defining the "DCPS$your_qname_NO_SYNC" = "TRUE" logical. This prevents problems with system<->printer PS/PCL mode initial negotiation. I know HP printers can be in an AutoSensing mode or hardcoded whether to expect PS or PCL data. If your printers are capable of this, and depending on how they're set, can fail the negotiation.

Do a Google for -> dcps no_sync <- you'll find info about this and more.

Cheers,
Art

[Ian Miller.]

which version of VMS and DCPS?

[Rene Stanger]

Hello,
thanks for your tipps!

I also tried the spool option with LDP queue, no difference.
The parameter dcps$_NO_SYNC = True just changed that my jobs does not hang in the starting state, it does hang in the printing state.

What is still confusing me is that it once worked fine with the MFP and after "some" network-changes it does not work anymore. But the post from Kalle tells me that it could have been just pure luck, that the MFP once worked.

We're using OpenVMS 7.3-2 on Alpha and DCPS V2.3

regards
René

[Karl Rohwedder]

I'm not sure if it makes any difference conc. your problem, but the actual DCPS version is V2.5, maybe you give it a try.

regards Kalle

[Wim Van den Wyngaert]

http://h71000.www7.hp.com/doc/82final/dcps/dcps025_release_notes.PDF

2.1.1 Mentions problems with MFP printers. And many other problems are mentioned furtheron.

Wim

[Jeroen Hartgers_3]

be carefull with lpd. The mfp must be configured for lpd. In default lpd printing is mostly not enabled on the mfp.

to create lpd queues always use the executable and never edit the printcap file. If you make a mistake in the printcap file its behavier is unpredictable. Wrong spaces are very difficuld to find, also authorisation and creation of the directories are also a problem.

use RUN SYS$SYSTEM:TCPIP$LPRSETUP.EXE for creating and deleting off lpd queues.