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

[Kyle Snavely_1]

Bojan,

It's worth a try, do you have any suggestions for symbiont code modification?

[Bojan Nemec]

Kyle,

The part where the terminal is assigned must be modified. This is the part which starts with:

MOVZBL #SMBMSG$K_PARAMETER_1,CODE ; Set item code


There you must get the username with the SMBMSG$K_USER_NAME code. Now you must do a loop with $GETJPI with JPI$_TERMINAL,JPI$_USERNAME and probably JPI$_MODE. Each iteration you test the username with the username you get with SMBMSG$K_USER_NAME and test the JPI$_MODE to see if it is equal to JPI$K_INTERACTIVE. When you find the user you continue with the terminal testing and allocation.

But be warn. If there are two or more users on the system which are logged with the same username it is possible that the job will be printed to the wrong terminal!

Bojan

[Bojan Nemec · Accepted solution]

Ok,

Probably some code will be better.
Now I am at home and have no hardware to test it.

First add the $JPIDEF macro to the system definitions part (at the beginning)

Comment out the TT_NAME:... line, then add this part:

-------------------------------------------
USERNAME: D_DESC ; Username
MODE: .BLKL ; Process mode
TERMINAL: .BLKB 8 ; Process terminal name
TT_NAME: .BLKW
.BYTE DSC$K_DTYPE_T
.BYTE DSC$K_CLASS_D
.ADDRESS TERMINAL
JPIUSERNAME: .BLKB 12 ; Process username
DUMMYLEN: .BLKW ; Dummy return length. Not used

JPIITMLIST:
.WORD 4 ; Mode length
.WORD JPI$_MODE ; Request process mode
.ADDRESS MODE ; Address of mode buffer
.ADDRESS DUMMYLEN ; Dont need buffer length
.WORD 8 ; Terminal max length
.WORD JPI$_TERMINAL ; Request terminal
.ADDRESS TERMINAL ; Address of terminal
.ADDRESS TT_NAME ; Address of terminal length
.WORD 12 ; Username length
.WORD JPI$_USERNAME ; Request username
.ADDRESS JPIUSERNAME ; Address of username buffer
.ADDRESS DUMMYLEN ; Dont need buffer length
.LONG 0
-------------------------------------------

and replace:
-------------------------------------------
MOVZBL #SMBMSG$K_PARAMETER_1,CODE ; Set item code
PUSHAL TT_NAME ; Address of descriptor
PUSHAL CODE ; Address of item code
PUSHAL @CONTEXT(AP) ; Address of symbiont ctx value
CALLS #3,G^PSM$READ_ITEM_DX ; Read PARAMETER_1
BSBW ERROR ; Check system service
-------------------------------------------

with:

-------------------------------------------
MOVZBL #SMBMSG$K_USER_NAME,CODE ; Set item code
PUSHAL USERNAME ; Address of descriptor
PUSHAL CODE ; Address of item code
PUSHAL @CONTEXT(AP) ; Address of symbiont ctx value
CALLS #3,G^PSM$READ_ITEM_DX ; Read USERNAME
BSBW ERROR ; Check system service
; Now we have the Username
MOVL #-1 , PID
180$:
$GETJPIW_S PIDADR = PID ,- ; PID
ITMLST = JPIITEMLIST ; Item list for Getjpi
CMPL R0,#SS$_NOMOREPROC
BNEQ 181$
; No such user!!!! Insert code to handle
; this situation!!!!!

181$: BSBW ERROR
CMPL MODE , #JPI$K_INTERACTIVE ; Test only interactive processes
BNEQ 180$
CMPC5 USERNAME ,-
@USERNAME+DSC$A_POINTER ,-
#^a/ / ,-
#12 , JPIUSERNAME
BNEQ 180$
-------------------------------------------

After that we have setup the terminal name and we can continue as if it was passed in the /PARAMETER.
I have not tested this code. Its up to you to test it.

Bojan

[Doug Phillips]

Kyle,

You probably already know this, but I'll say it for posterity.

Depending on your terminal emulator the printer will either be the one assigned within your emulator or the windows default printer; not just your locally attached printer. You will need to consider the windows port and spool settings, and realize that some emulators do a better job than others working with or bypassing the windows drivers.

The [5i and [4i sequences sent by the symbiont are "Printer controller mode" On and Off, respectively. If you have access to and control of your source code, and if by chance your programs use a common wrapper for opening and closing your print device, you could do as we have done:

As with your software, a user can select a printer. If the user has selected the "Windows" printer, our progam uses device "TT:" and sends [5i after the printer open, and [4i after close.

No VMS symbiont involved, and it works for all clients that are actual or emulated VT's.

-Doug

[Kyle Snavely_1]

Thanks everyone for the great replies. I have talked to some people in house and they seem confident that they will be able to modify the application to send the printer control codes.

Kyle

[Doug Phillips]

Kyle,

One little note: You could simply use the terminal channel you have open, but I'd go ahead and open up another channel for the printer. This keeps the code change to a minimum.

And one caveat: Any other output to the screen while the ON code is in effect will print on the printer. If you have to display an error, warning, or progress message, send the Off code before and then send the On code afterwards. Again, pretty easy to code if you use a common message routine.

You might also consider having your printer control routine set a "Printer_status=TT_open" or "=LP_open" variable when the printer is opened and clear "Printer_status" when it's closed (or similar logic). Then, if you need to do screen I/O you can test whether or not you need to send the escape codes.

-Doug