missing a character in print out

[Bill Hassell]

> I have been dealing with this vendor for months, while they do not agree anything at the software level.

This vendor has put your company at severe risk because they have bypassed all supported printing methods and refuse to help in the troubleshooting steps. I would hope that you have some choices for a different vendor as soon as possible. Printing financial reports where a character is dropped at random can easily lead to lawsuits. They have not provided any evidence that their software is not at fault, so you must demand that they provide a method to prove what they sent to the printer is correct. If this was a supported lp spooler design, it would be trivial to make a copy of each print job with no modification the the application.

I would still point you back to the JetDirect External box to select a standard Centronics interface and not the high performance EPP option. Have you looked at the JetDirect settings with your browser? You can also telnet to the JetDirect box and turn off special printer features. Do you have the option to change printers, specifically a more e=recent model, perhaps one that the vendor will support with a JetDirect interface.

[OldSchool]

Grace,

I've re-read this entire thing. I note that "you think you know the name" (mport), you see it "mport" in /etc/hosts, ping it, and so on.

you say "lpstat -v | grep mport" doesn't return anything and that you can't find a file "mport" in /var/spool/lp/interfaces.

as noted above, there is NO requirement that the queue/destination be called the same thing as the entry in the hosts file. Additionally, it is not apparent if you followed what A. Clay was saying regarding "PERIPH=" above, so....

in /var/spool/lp/interfaces:

grep mport *
and/or
grep *

Does that return anything???

[Grace Li]

Sorry for late reply. I am tied up with the "day light saving end time". Some of our HP UX servers are too old to have a patch, I have to manually check and adjust. Deeply appreciate all your suggestions. Let me check and provide details shortly.

[OldSchool]

"Sorry for late reply. I am tied up with the "day light saving end time". Some of our HP UX servers are too old to have a patch, I have to manually check and adjust. Deeply appreciate all your suggestions. Let me check and provide details shortly. "

just copy /usr/lib/tztab from a patched server to the "too old to be patched"

I *hope* you didn't change the system clock!

[Grace Li]

Great! I have been seaching for the command to manually set the end time. I did not started yet to adjust the time until this saturday night.

[OldSchool]

after moving the tztab you need to stop / restart long running processes (cron, databases, etc) or reboot server sometime before the change.

[Grace Li]

so a reboot is necessary after changed the tztab?

[OldSchool]

some processes that "run" all the time, like cron, only read the tab on start-up. If you know which processes *might* be effected, you could just stop/restart those. Since reboot starts everything, there isn't anything to be overlooked by accident.

[A. Clay Stephenson]

The original versions of the libc() routines that handled date conversions to/grom epoch seconds did reread tztab each time --- at the cost of performance --- but later patches/versions cached the tztab entries so that a given process would not need to reread an all but static file each time. It was a good trade-off but the price is that long-running processes must be restarted. It's easy to find the obvious ones like cron and databases but others are easy to miss. The safest approach is to schedule a reboot after the tztab update has occurred.

The attached Perl script, dst.pl, will allow you to safely test the tztab entries. It doesn't actually change the system time --- because that does not change anyway --- the only thing that changes is how those seconds since 1-Jan-1970 00:00:00 UTC are displayed.

perl dst.pl will display the exact seconds before and after the time changes.

Invoke as dst.pl -u for full usage.