Printing Problem from One Cluster Node

[Emad Omar]

Hi all,

I have a printing problem appeared when I print the same job from one node of two nodes cluster. I have got a correct printout from node-B while I have a shifting (uncorrectable printout)when I print multi pages through the same job from node-A.
The cluster configuration done as one system disk and the same queue manager plus the same sysuaf.dat file.
(This is a new cluster system migrated from an old single system after buying new Servers and we did this migration due to a retired software installed and running).

The only differece between two nodes is the sysgen parameters.So are there any system parameter affects on this issue??!!

Please advise . . .

Regards,

Emad Omar

[Wim Van den Wyngaert]

Try dir sys$library:*.tlb
and see if all files are in sys$common (esp. form libraries).

Else : what kind of printing (lpd, lat, dcps, ...), versions ?

Wim

[Volker Halle]

Emad,

before answering lots of questions, could you provide a 'SHOW QUE/FULL/ALL printer-queue-name' from both nodes ?

Volker.

[Emad Omar]

Dear all,

Thank you for your fast reply.
regarding the $show queue/all/full I need to tell you that each nodes have the same definition, because we start and intilized the queue using the same script on sys$common.
On other hand we are using LAT Protocol and for this job we are using the following command :
$print/device=ltaxxxx filename

Kind regards,

Emad

[Karl Rohwedder]

Emad,

since you say the pages are shifted, can you check and compare the terminalsettings of your LTA devices ( SHOW TERM LTAxx)?regards Kalle

[Wim Van den Wyngaert]

Did you try the dir on both cluster nodes to see if all form libraries are really the same ?

Wim

[Volker Halle]

Emad,

by not providing detailled information, you only lead people to ask speculative questions. If Wim could have seen the SHOW QUE/FULL/ALL queue-name output, his questions about setup libraries would have been unnecessary, if that queue does not even use them...

Please also try to explain, how the print output differs if printed on node node or the other.

Volker.

[Phil.Howell]

If lta devices are involved, then I believe some terminal characteristics are derived from sysgen TT parameters.
Start with TT_DEFCHAR and TT_DEFCHAR2
Phil
ps
HELP PRINT /DEVICE on my system
says that /DEVICE is synonymous with /QUEUE
and its use is not recommended
What happens on each node if you
$copy LTA123:

[Phil.Howell]

also...
The lta device will show as allocated on the node where its queue is started.
I assume this is node-B in your case, and print/device from node-A is the problem?
Phil

[Mahmoud_1]

Dear All,
I'm Emads colleague and I will continue this Issue with all, Today I'll try all what you asked.
Please be patient.
Mahmoud.

[Mahmoud_1]

Dear All,
I tried all what you asked me and I logged it on the attached file.
Note:
1- I tried the Copy command to the LTA85: and LTA12: I received the same output.
2- When I print the same job using PRINT/QUE not /DEVICE The output is OK.
3- Programmers cant change the code in the application to use /QUEUE.
Please advice.
Mahmoud

[Volker Halle · Accepted solution]

Mahmoud,

I see a couple of inconsistencies in your problem description:

The ACC_TAX queue is running on MOGA1::LTA12: - it is NOT using the LATSYM print symbiont, which would be the default and supported way to print on a printer connected to a terminal server. As the queue in running on only one node in the cluster, the processing of the print file is always done by the print-symbiont on that node and it shouldn't matter on which node you submit the job using the PRINT command.

There is no device control library associated with the ACC_TAX queue, so the listing of the .TLB files is irrelevant.

You've only shown the TT system parameters and LATCP info from node MOGA2. That information is also irrelevant, as the print symbiont is running on MOGA1.

Try STOP/QUE/NEXT ACC_TAX, then print the job from both nodes and look at the job attributes using SHO QUE/FUL/ALL ACC_TAX. Any differences ?

Using PRINT/DEV=xxx or PRINT/QUE=xxx should behave the same. xxx must be a valid queue name.

The example command given:
$print/device=ltaxxxx filename
cannot work, if there is no LTAXXXX device queue.

If you use a COPY command and the device is spooled, the file will end up as a normal print job in the ACC_TAX queue.

What is LTA85: and what does it have to do with this problem ?

Did you consider, that a previous print-job printed on that queue may influence the settings of the printer and thus cause you output to be different ?

Volker.

[Mahmoud_1]

Dear Sir,
I want to clarify this:
1- All queues defined on Moga1 have the same problem and users must connect to Moga2.
2- The SYSGEN params I uploaded is from MOGA2 and I checked it on the screen for Moga1.
3- All things I didnt upload it from one node its the same with the other node.
4- Why its OK on Moga2 ( The goined New Member on the cluster ) and its not OK on the primary node ( Which I created the Cluster from ) and it was OK befor the Cluster Creation ?
5- All what we did from the beginning:
a. Image backup from Old system restored on new Machines.
b. Cluster config procedure performed
c. All new License activated.
d. Cluster conf procedure performed to goine the new system Moga2
e. System started and all tests OK.
Regards

[Volker Halle]

Mahmoud,

please try the following:

$ STOP/QUEUE/NEXT ACC_TAX

Login to MOGA2 and print a document on that queue.

Login to MOGA1 and print the same document on that queue.

Upload the result of SHO QUE/FULL/ALL ACC_TAX

There should be 2 print-jobs pending in that queue.

Then start the queue. Which printout is correct ? And what's wrong with the 'bad' printout ?

Volker.

[Phil.Howell]

How does your system do the print?
Is it from dcl using
$print /dev=abcd
or from within a program?
How does it determine which queue or device to print on?
You may be able to get around this by creating a new printer in your application
(eg abcd) and then defining a logical name to point to a queue name by
$define abcd
vms should do the logical name translation when you try to print to abcd.

You can also associate a logical name with a lat port using
$lancp create port /logical=
see lancp help create port for details

Phil

[Mahmoud_1]

Dear All,
Thanks for reply,
I did the PRINT/DEV command
I uploaded the log file for both MOGA1,MOGA2
Regards
Mahmoud Ad-Dabbas

[Volker Halle]

Mahmoud,

both print-jobs have identical attributes. They both will be printed via the same standard PRTSMB print symbiont running on MOGA1. The printer output therefore should be the same.

What happened, after you started the ACC1 printer queue ? Was the first printout bad and the second one o.k. ? What's the difference between 'good' and 'bad' ?

If you would repeat the same experiment and FIRST print from MOGA2, then from MOGA1, then start the queue, would the 'bad' printout come out after the 'good' one ?

LAT queues should normally be operated by the LATSYM print symbiont. Although I'm not yet sure, what the problem is, you could use LATSYM as your print symbiont:

$ INIT/QUE/PROC=LATSYM ACC1

You can reverse this with: INIT/QUE/NOPROC ACC1

Volker.

[Jan van den Ende]

Mahmoud,

I fully agree with Volker: printers on LAT devices should use the LATSYM processor!

Proost.

Have one on me.

jpe

[Mahmoud_1]

Dear All,
Thanks for reply.
I tried today to check this problem, I recreated the queue from Node a ( MOGA1 ) that have the problem and I performed the print job it printed OK from both nodes.
So are there any commints on this issue?
/processor=LATSYM added to the INIT command but customer needs to restart the system to check if problem solved by this or not,
So if any recommendation before tomorrow (the date that we will test the printing after restarting the cluster) please let me know.
Regards
Mahmoud