Printing

[Eric Zimmerman_1]

Thank you everyone for the information. I am convinced that it is not going to be possible. I spoke with Ricoh support last night. I told them we have an OpenVMS server connected to a MPC3500, they said â you have a what connected to a MPC3500?â

[Jan van den Ende]

Eric, Hoff,

Hoff wrote:
>>>
I would see of switching to lpr/lpr makes any difference around how this Ricoh works. (I'd tend to doubt that, but it's worth a try.)
<<<

In our experience, that sure makes a difference, but probably NOT one you like!

Int the LPD/LPR protocol, there is no such concept as a jobSTREAM, and therefor, _EACH_ file is treated as a separate job.
And in a typical VMS queue setup, _SEVERAL_ files are sent in on print command. Each (setup-, separate-, reset-) module is treated as a SEPATATE printjob, allowing for prioritising by size, for intervening jobs, etc. And of course a printer reset after each job, even if that was a Setup module...

You _CAN_ mimic the M$ behavior of composing your complete job before sending, by sending your VMS printjobs (with... TELNETSYM) to intermediate storage ( say "spool" ? ), and printing the intermediate file with LPD, snd there can be good reasons to do that.

hth

Proost.

Have one on me.

jpe

[Hoff]

The lpr/lpd suggestion was in response to the propogation of the security information, and not regarding differences at the printing and print processing level.

In most cases I've encountered, lpd and telnet are roughly equivalent, and if one doesn't work to your liking, try the other. Different vendors and different implementations can have different bugs.

As for talking with Ricoh support, I'd encourage you to use a popular Linux distro as the name of your host operating system, and work backwards from there. The folks working off the scripts will more commonly recognize a RedHat distribution than OpenVMS, and most folks here can translate from RedHat instructions and answers into OpenVMS answers.

Yes, the commands are different, but LPD and telnet and the mechanisms and such are the same. If the support folks are willing to email, fax, IM over a file containing the Linux instructions, we can usually easily translate the material into OpenVMS.

I've used this technique with great success on a number of occasions, and it usually gets you past the hard support fault and resulting call outswap you seem to trigger when you use the term "OpenVMS".

Most of the Linux driver lists will list partial and unverified support for this printer. FWIW. When I'm picking a printer, I almost always look at the DCPS support list, and at the Linux driver availability.