> Since the user logical tables get processed before system tables, you could
> redefine MULTINET_SPOOL in the user's login. This would take all of the
> queues that Multinet handles. I think this would work.


I don't understand how that would help.
(I'm not saying it wouldn't, just that I don't understand.)

We have many Multinet queues that we wouldn't want disturbed.

Isn't that logical used by the multinet queues to decide where to write
their intermediate files? The print symbionts are not running as user
jobs, so I don't understand why they would use an individual's
logical name table.

Are you suggesting defining a print queue while logged in as an
unprivileged user so that logical is used by the newly defined print
queue?

Selden


> Mark Kattalia
> CALLAN ASSOCIATES Inc.
> 101 California St. Suite 3500
> San Francisco, Ca. 94111
> (415) 274-3099
> kattalia@callan.com




> # -----Original Message-----
> # From: Selden E Ball Jr [mailto:SEB@LNS62.LNS.CORNELL.EDU]On Behalf Of
> # Selden E Ball Jr
> # Sent: Friday, October 20, 2006 7:38 AM
> # To: info-multinet@process.com
> # Subject: print to file?
> #
> #
> # Is there any way to persuade a Multinet print queue
> # to send print jobs to a file in a user's directory?
> #
> # For example, can the spooling directory be redefined
> # on a per-queue basis?
> #
> # I don't see any mention of a "print to file" option in the
> # Multinet documentation. Have I overlooked it?
> #
> # Apparently it may be a future option in DCPS, but our need is now :-)
> #
> # Alternatively, does anyone know of another print symbiont that
> # can do this?
> #
> # There seems to be a Windows based solution (sending print jobs to
> # queues on individuals' PCs) but I'd like to avoid that if possible.
> #
> # Our business office is trying to reduce the amount of paper records
> # they have to keep. The mainframe application that they're running
> # sends print jobs to lpr/lpd queues that are served by our
> # VMS/Multinet system.
> #
> # They're currently testing scanning the printer output and using OCR,
> # That's what they'll have to do for existing documents, but it'd
> # be nice to avoid that effort for future documents.
> #
> # I think that one queue per user, each writing a specific
> # directory would be an acceptable solution.
> #
> # Thanks for whatever help you can provide.
> #
> # Selden
> # ======
> # Selden E. Ball, Jr.
> #
> # Cornell University Voice: +1-607-255-0688
> # Laboratory for Elementary-Particle Physics FAX: +1-607-255-8062
> # LT105 R. R. Wilson Laboratory
> # http://www.lepp.cornell.edu/~seb/
> # Dryden Road Internet: SEB@LEPP.CORNELL.EDU
> # Ithaca, NY, USA 14853-8001 HEPnet/SPAN: LNS62::SEB =
> # 44284::SEB
> #