Redirecting printer output

[Music]

Is it possible to "point" a printer device (e.g., LRA0:) or print queue (e.g., sys$print) to different print queues for separate, simultaneous login sessions? That is, can a pseudo-device or queue be defined that sends its output to user-login-specific print queues?

Example:

Pseudo device name: ZZA0:
Bob's Login: ZZA0: sends output to sys$print1
Jane's Login: ZZA0: sends output to print2

Both are logged in at the same time.

Any suggestions or pointers in the right direction are appreciated.

Thank you,
Bobby

[Bill Hall · Accepted solution]

It is possible to define logical names that equate to any queue, batch or print. The logical name can be defined in any appropriate name table, process, group, system, cluster.

I would recommend using SYS$PRINT as a logical name rather than an execution or generic queue name. You can then define a default value for SYS$PRINT in the system table and define user specific values for users in their process tables via LOGIN.COM.

$DEFINE/SYSTEM SYS$PRINT DEFAULT_QUEUE

In a user's LOGIN.COM:

$DEFINE SYS$PRINT MY_DEFAULT_QUEUE
or in your example for Bob:
$DEFINE SYS$PRINT sys$print1
for Jane:
$DEFINE SYS$PRINT print2

Both users would be able to issue the same print command "$PRINT any_file.lis" but the output will appear on different printers.

[Volker Halle]

Bobby,

if your application submits print-jobs to a print-queue, the logical name scheme described by Bill is the way to go.

But if your application expects to write output directly to a printer device (e.g. LRA0:), you would have to add an additional step. There cannot be 2 devices in the system with the SAME name.

In this case, you could create pseudo terminal devices using

LATCP> CRE PORT LTAnnn:

and set those devices spooled with

$ SET DEV/SPOOL=queue_name LTAnnn:

Then you define your logical name

$ DEFINE/JOB ZZA0: LTAnnn:

(to individual LTA devices for each user in their LOGIN.COM) and have your application send the output to ZZA0:

E.g.
LTA9000: -> spooled QUEUE_X for user x
DEF/JOB ZZA0: LTA9000: for user x

LTA9001: -> spooled QUEUE_y for user y
DEF/JOB ZZA0: LTA9001: for user y

You would need to define ONE LTAnnn: pseudo terminal for each queue, to which the application output should be sent.

Volker.

[Jan van den Ende]

Bobby,

we use the printqueue, and not the print-to-device scheme.

This may not be relevant if you have few users, but becomes a real issue with 6000+ users and 700+ printers, located over 100+ KM^2.

The way to implement this in a user-friendly, and not-support-intensive way, is by this scheme:

Formalise the /DESCRIPTION for each printer in a way that makes them easy to find for the end-user.

Create a (menu-) program that presents the printers, grouped in a way that is conveniant to the users. Make that program find the current printers dynamically (eg, F$GETQUI), because that collection tends to have high mutation rate.

Upon choice of a printer, generate SYS$LOGIN:DEFINE_SYS$PRINT.COM, a one-liner with obvious content.

In SYLOGIN, execute SYS$LOGIN:DEFINE_SYS$PRINT.COM, and present the /DESCRIPTION.

This way, the chosen printer remains in effect over sessions, and also for batch jobs. Of course, the user can adapt at will.

---

We even took that some steps further. Since most of the users access the VMS apps from a Citrix desktop using a terminal emulator, (and all usernames for a person on both platforms are defined to be the same), at selection of a VMS app we find the default or chosen Citrix (desktop) printer, and build SYS$LOGIN:DEFINE_SYS$PRINT.COM from that. This we copy to VMS, as well as a file AUTOSTART_VMS.APPLIC that specifies the chosen app. And in SYLOGIN, after defining SYS$PRINT, if AUTOSTART_VMS.APPLIC exists and is less than 60 secs old, then we bypass everything else, directly execute the app, and logout.

Hope to have given you some ideas.

YMMV.

Proost.

Have one on me.

[Robert Gezelter]

Bobby,

The comments preceding mine are correct. You can create a transparent environment, where each group, department, section, and user has defaults, and they all work together well. In some cases, the spooled devices are also part of the question.

My whitepaper, "Inheritance Based Environments in Stand-alone OpenVMS Systems and OpenVMS Clusters" described how to build environments of that type to provide users with a seamless environment tailored to their needs (see the reprint available from http://www.rlgsc.com/publications/inheritance.html for details)

I hope that the above is helpful.

- Bob Gezelter, http://www.rlgsc.com

[John Travell]

I think the correct url is:
http://www.rlgsc.com/publications/vmstechjournal/inheritance.html
Probably the classic mistake of writing things from memory and not actually checking them! :-)

[Wim Van den Wyngaert]

I think the problem is more complicated.

In an application, a file should be created that needs to be printed. Depending on the file name, program name, user name, date or whatever conditions that you can imagine, the file must be printed on 0, 1 or more printers. Or it must be e-mailed or faxed or whatever. And printed means also using different forms, different types of printers, different number of copies, ... .

So, in my opinion, you should execute a script instead of a print command and this script should receive all the parameters (e.g. via symbols) and depending on what is wanted, do the necessary.

This doesn't rule out the system of Jan that could be used in parallel (or as an implementation of 1 of the prints).

I implemented this once on Unix but the customer found it "too open" meaning that he didn't wanted to fill the contents of the script.

Wim

[Music]

Thank you all for the advice. I'll be back at work tomorrow to play with it. Your examples have been VERY helpful.

Bobby