Print Symbiont Fun - Transparent Printing

[Kyle Snavely_1]

I grabbed the symbiont code that was attached to a Wizard's answer about transparent printing: http://h71000.www7.hp.com/wizard/wiz_2680.html

I was able to compile and link the code successfully and it almost does what I want it to do, but not quite. The code allows you to transparent print to a slave printer attached to a terminal via a regular printer queue. The only problem with this is that you have to pass a /parameter= for it to work properly.

My question is: how can I make this work so I don't need to specify a parameter of the terminal name? I would like it to default to the terminal name of the terminal that kicked off the print job.

Can this code be modified to do this or does anyone know of pre-existing symbiont that does what I need it to do?

Thanks!

[Ian Miller.]

The problem is that the symbiont is running in a seperate process and could be servicing requeets from anywhere. The parameter is used to tell it what it needs to know. You could write DCL to translate the TT logical name and pass the result as the paramter.

as a guess how about this

$ PRINT/PARAM='F$TRNLNM("TT:")'/QUE=xx filename

[Volker Halle]

Kyle,

the print symbiont code itself cannot obtain any information about which process submitted the print job. It could obtain the username of the submittor and if that user is still logged in, you could obtain the terminal name and so on ...

How do you 'kick off' the print job ? With a DCL command (PRINT/QUE=...) ? If so, you could probably re-define the PRINT command in a LOGIN command procedure for the user to something like: $ PR*INT:==PRINT/PARA=('F$TRNLNM("TT")')

If there are unique usernames, a logical could be set during LOGIN like username_PRINTER = TTAx: and the symbiont could translate the logical after obtaining the submittor name.

Volker.

[Kyle Snavely_1]

Thanks for the excellent replies, but unfortunately, I am not printing from the command line. The print jobs are coming from MUMPS... ISM to be exact. I do not think there are any facilities in our application to specify DCL to submit a print job. As far as I know, our application only allows us to print direct to a queue device (mnemonic) such as LTA555: without the ability to specify any parameters. That is why I was hoping to get the symbiont to recognize the device name that the print job was coming from.

[Jan van den Ende]

Kyle,

let me try to get the picture so as I can understand unambiguously.

- Is your MUMPS set up to print hardcoded to a specific device?
or
- Can a specific device be defined for the applic to use (fixed) for the duration of an applic up instance (maybe by setting up & pinpointing)
or
- Do you have to somehow specify the printer device?

- Is there one fixed printer for all users, or are diferent printers (how?) assigned to different users?

In short, WHEN, and HOW, is the printqueue "decided" (ie, setup, started, chosen).

I assume you have tried logical names already.
You wrote "can only chose "a" device". How fixed is that syntax? Can you define dummy devices (like eg CCA111:) and mis-use those?

--- too many loose end for me now to really try for a solution. However, I suspect there will be a way to trick the app into believing you.

Oops. Did I just have a flare of optimism? An pessimist only is an optimist with experience...

Proost.

Have one on me.

jpe

[Bojan Nemec]

Kyle,

I give a (very very fast) look to the symbiont. Now I have no time to test it but it seems that if you substitute the lines:
CMPL #PSM$K_START_TASK,@FUNC(AP)
to
CMPL #PSM$K_START_STREAM,@FUNC(AP)

and

MOVZBL #SMBMSG$K_PARAMETER_1,CODE ; Set item code

to

MOVZBL #SMBMSG$K_DEVICE_NAME,CODE ; Set item code

it will work with the terminal which you set in the START/QUEUE/ON=terminal.
As said I give a very fast look to the symbiont and I am not shure that this will work. You must test it.

Bojan

[Kyle Snavely_1]

Jan,

The users can select in the application which LTAxxxx: device they would like to print to. The LTAxxxx: device must be specified in a device table prior to users being able to print to that device. The device in the device table must match that of a queue name at the vms level.

This is all stemming from the printing need of remote offices that only have a Windows Terminal Services session to a terminal emulator that connects to the VMS/MUMPS application. There are no provisions to allow a ucx queue to point to a printer at the remote site because there is no network path back to the remote site.

So the idea would be to map the remote office's printer to the windows terminal server allowing the terminal emulator to get a transparent print from the MUMPS application and pass that on to the mapped printer which is actually the printer in the remote office. (that should be confusing enough)

I can define any any device in the device table as long as I can also specify a printer queue and a blank LAT port.

There is not a fixed queue for all users. Users can choose any valid print device available. In this particular scenario, I was looking at creating a LTAREMOTE: device that would dynamically print to the users terminal.

If user 1 was at office 1 (TNA1:) and user 2 was at office 2 (TNA2:) both users could print to LTAREMOTE: and it would detect if the user was logged in on TNA1: or TNA2: and print to the proper device.

[Jan van den Ende]

Kyle,

I have sincere doubts about being able to print "back" over your TNA connection.
At the very least, the return signal would have to have steering codes whether to display a signal on the screen or output to the printer.


I never tried this, just a theoretical scenario!


You have the IP info on the printer, I assume.

Suppose, you reserve a LTA device.
Set up your print queue such that is is acceptable to the app.
Configure as normal.

Now, (mis-)using the LTA name, INIT a TCPIP$TELNETSYM printqueue to your printer.

I think I would leave the LTA device existing.

(various threads about that to be found in this forum)

I guess it may be worth the try, but I am not responsible for your lost time if it does not work!

(This kind of trickery will need some decent documentation if you ever want it to be understood by a later system manager!!)

I am curious of your results!

Success, & good luck.

Proost.

Have one on me.

jpe

[Kyle Snavely_1]

Telnetsym is how we currently print to our IP printers. In this scenario, we cannot use that method as we have no IP path to the printers in the remote site. The symbiont that I referenced in the original message works quite well at printing over the TNA device. Unforunately, we must pass the TNA parameter to the symbiont each time we print.

Ian's suggestion works well when printing from the command line, but it is not the case. I will see if we can alter the application to pass the TNA of the user who requested the print job to the print queue. I guess that is the only way to applish this.

Thanks for the help everyone.

[Bojan Nemec]

Kyle,

Unfortunately the pid of the submitor is not saved in the queue entry when you submit a print or batch job. With such an information it will be possible to modify the symbiont to print to the terminal which is associated with the pid. The only information you can get is the username or uic of the entry owner.

So, if yours users login each with its own username and you have no users which are logged in with the same username it will be possible to modify the symbiont code to search for the terminal on which it must print.

Bojan