HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
cancel
Showing results for 
Search instead for 
Did you mean: 

Printing

 
SOLVED
Go to solution
Eric Zimmerman_1
Occasional Advisor

Printing

We have new Richo MPC3500 Color Printers. The printers can block users from printing color by username. We have a Queue setup on the Open VMS server to print but, the username is not sent with the print job. Is it possible to configure the queue to send the username to the printer? I am not familiar with OpenVMS.

Thank you

Eric
12 REPLIES
Hoff
Honored Contributor
Solution

Re: Printing

Please post the print queue definition.

$ SHOW QUEUE name/FULL

Details from that display will indicate which path out to the printer is being used, and possibly some added details. The usual paths are telnet, lpr/lpd and (if this Ricoh printer has Postscript) potentially DCPS.

Please also post details of the particular IP stack in use. With the TCP/IP Services product (one of several IP stacks), that information is available with the commands:

$ UCX
SHOW VERSION

Ricoh should be able to provide some details, too, around which printing path(s) are used with this color control mechanism, and how these are configured.

Depending on which path is used, there are various configuration files.

http://h71000.www7.hp.com/doc/83final/6526/6526pro_contents_006.html#toc_part_6

I know of nothing specific to sending or not sending the username, however. That happens as part of the protocol, and the values are generally displayed (or selectably displayed) as part of the printer-local banner processing.

--


This could also be a relay queue -- not a network printer, but a printer directly served by some host system -- and empirical and long-standing evidence indicates that's difficult to get right, and the configuration and troubleshooting process can be quite problematic. I always recommend printers with built-in NICs. Anything else is just too much work to be worth the token savings.

Eric Zimmerman_1
Occasional Advisor

Re: Printing

$ show que/fu mte1
Printer queue MTE1, idle, on MONROE::"10.1.0.67:9100", mounted form HPLETTER
(stock=F1L66)

/BASE_PRIORITY=4 /DEFAULT=(FORM=HPLETTER (stock=F1L66)) /LIBRARY=HPLJDEVCTL
Lowercase /OWNER=[SYSTEM] /PROCESSOR=UCX$TELNETSYM
/PROTECTION=(S:M,O:D,G:R,W:RSM) /SCHEDULE=(NOSIZE) /SEPARATE=(RESET=(RESET))


TCPIP> show version

HP TCP/IP Services for OpenVMS Alpha Version V5.4
on a AlphaServer ES40 running OpenVMS V7.3-2
Hoff
Honored Contributor

Re: Printing


It looks rather weird to see the telnet port going into port 9100 -- is that the way that printer is supposed to be configured? Port 9100 is usually the "raw" port. DCPS and other such direct-printing tools tend to use that port.

Telnet printing traditionally goes into port 23, and that may well be where Ricoh is expecting to receive the telnet-based information.

LPR connects into LPD port 515 on the target.

The "fun" here is that there isn't a whole lot of standardization among printers, even from the same manufacturer.

Try switching to lpr, or switching telnet over to port 23.

In any case, you can generally bring up a second print queue in parallel to your production queue, and test with that -- that modification should not disrupt this print queue.

Also try connecting into port 80 using a web browser -- many printers will have a web server on that port. See if you can find anything interesting there.

If you can find Unix or Linux documentation for this printer in the Ricoh documentation or at the Ricoh web site, that can potentially be enough to determine what steps are required for OpenVMS.

On a related matter, you will want to load the current ECO for V5.4. The TCP/IP Services ECO kit is stored here:
ftp://ftp.itrc.hp.com/openvms_patches/alpha/V7.3-2/

There are some useful fixes in the ECO.

Some other info on printing and Ricoh printers:
http://h71000.www7.hp.com/wizard/wiz_0867.html
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=864880

Here's an odd Ricoh doc that has some IP configuration information -- there may well be a newer copy of this accessible in some Ricoh support database somewhere:
http://www.cubhis.org/about/security/docs/RicohCopierSecurityWhitePaper.pdf
Jan van den Ende
Honored Contributor

Re: Printing

Hoff wrote

>>>
It looks rather weird to see the telnet port going into port 9100
.
.
.
Telnet printing traditionally goes into port 23
<<<

Wow! Never knew that! And we are using TCPIP$TELNETSYM (almost) exclusively, on various HP, some Kyocera and some Nashuatec printers, all on port 9100; and hardly any (communications related) troubled worth mentioning!

One is never too old to learn something new. :-)

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Eric Zimmerman_1
Occasional Advisor

Re: Printing

$ show que/fu mte1
Printer queue MTE1, idle, on MONROE::"10.1.0.67:23", mounted form HPLETTER
(stock=F1L66)

/BASE_PRIORITY=4 /DEFAULT=(FORM=HPLETTER (stock=F1L66)) /LIBRARY=HPLJDEVCTL
Lowercase /OWNER=[SYSTEM] /PROCESSOR=UCX$TELNETSYM
/PROTECTION=(S:M,O:D,G:R,W:RSM) /SCHEDULE=(NOSIZE) /SEPARATE=(RESET=(RESET))

We changed the port to 23, tried to print and nothing comes out. Is what we did correct?
Eric Zimmerman_1
Occasional Advisor

Re: Printing

Currently, when a print job from the openVMS print que is sent to the Ricoh printer there is no username associated with the print job. We can see this on the web interface of the Ricoh printer. The printer needs the username to check if the user has permission to print to the printer. Is there a way for VMS to send the username to the printer?
Bill Hall
Honored Contributor

Re: Printing

Eric,

If you qualify the VMS print command with the /flag (or set the queue to do it by default), a "flag" or "banner" page will be sent to the printer. The username and some other things will be printed on the flag page. It would be up to you or the Ricoh to figure out how to use it ;-).

Bill
Bill Hall
Doug Phillips
Trusted Contributor

Re: Printing

Port 9100 is most commonly used. Port 23 might get you to a management login, or not, but you certainly don't want to point your queue there.

Most newer printers use HTTP for management, but might also allow telnet.

Don't know about the Richo, but it I suspect the username setup might be designed for Windows networking.
Hoff
Honored Contributor

Re: Printing

Ok, looks like the Ricoh printers can use port 9100 as the target port.

Can you confirm this printer is the Ricoh Aficio MP C3500? (If so, there's a boat-load of management in this particular box, too.)

For grins, "telnet printername 9100" and enter some text. Usually when you disconnect the session, the printer will print what you have provided.

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.)

From what I can locate in the Aficio MP C3500 manual, the user (and password) information looks to arrive over SMB protocols, and OpenVMS doesn't provide those. I don't see anything about telnet or lpr/lpd printing, other than support for it -- the information on username and password looks tied to Microsoft protocols. I (also) don't see a color-related control mechanism, however. I do see gazillions of references to SMB.

Looks like "no"...
Eric Zimmerman_1
Occasional Advisor

Re: Printing

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
Honored Contributor

Re: Printing

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
Don't rust yours pelled jacker to fine doll missed aches.
Hoff
Honored Contributor

Re: Printing

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.