PSM: BSD Functionality, Administration and Backup.
ITEM: RTA000145260
Q:
Topic thread:
Printer Systems (PRINT)
Printing Systems Manager (PSM)
I have a customer that is interested in PSM, but has a few questions.
If they implement PSM, they would like have it work as follows: They
have SAP running on a 3rd party unix platform. They want to send the
output from SAP to a PSM server (running AIX of course). They have a
large distributed network of about 200+ NT servers with about 10-12
print queues on each. They want the PSM server to route the output to
each NT server.
Questons:
1) We understand that there is not a PSM NT server, however I've seen
items that seem to indicate that PSM can route data to printers on
remote servers with addresses of \\xxxxx\yyyyy. It would seem,
therefore, that the above scenario would work, but I'd like to get
some verification of this, and find out if configurations like this
have been tested.
2) Administration: My understanding is that there is an administrative
GUI or a command line interface. Also, I understand that administration
needs to be done at the server. My customer would like to know what
difference in function there is, if any, between the command line
interface and the GUI. Would it be possible to run the command line
interface from a non-AIX workstation and do administration (say,
TELNETing into AIX)? What implications would this have, specifically in
the area of troubleshooting?
3) Because of the number of printers (2000+), capacity planning becomes
an issue. Will one PSM server be able to handle this?
4) Let's say we implement PSM, and the PSM server (or servers) go down.
What kind of backup/recovery scenarios exist for PSM? Could we have a
hot standby that immediately (or at least very quickly) takes over the
workload?
Answers:
If they want the NT servers to be driving the printers, then what is
their need for PSM? I ask this because the PSM logical printers would
need to be setup as BSD printers which would not allow PSM to provide
any load balancing or functionality it was designed for. I don't see
PSM providing any value-add to the customer if I understand correctly
what they would like to do.
But to answer your questions:
1)Yes, using this addressing convention should work. Here are the
comments from the developer:
"You should be able to route jobs from PSM to an NT printer via a PSM
BSD printer with the appropriate printer-command, provided that the
NT box supports the standard UNIX lpr/lpd protocol. There was a
recent PTF (U452276) that included a fix (IX72231) to correctly
handle backslashes in the printer-command string."
2) The command line interface is every bit as functional (if not more)
than the GUI. The GUI is much more friendly and because it is
visual, the status of printers/servers can be much more easily
assessed. Telnetting in from "non-AIX" workstations and administering
PSM from the command line (or the GUI) would not be a problem. The
GUI is also helpful for operators that are not as familiar with the
AIX command line.
3) The amount of printing activity and the size of the system (cpu,
disk, memory, etc) will depend on whether one PSM server would be
adequate or not. Please get the PSMSIZE PACKAGE from the PRINTERS
disk and send the information back to PRTHELP. We can then work with
you on the sizing.
4) There is one customer using PSM in an HACMP environment. So a
backup/recovery "hot switch" solution would be with HACMP.
Q:
I have gone back to the customer with your concerns about how they are
looking to implement PSM. They have clarified my understanding.
Some of the printers that are being driven by the NT servers are IP
addressable, but not all. So, the printers that are not IP addressable,
and have be driven by NT need to be routed through the NT server.
There is also another situation. They run Jetforms sw, which has a
server component. So, when they want to print from Jetforms, they need
to route the data through an NT server with Jetforms install.
For the printers that are IP addressable, and when these IP addressable
printers are not printing data that needs to be routed through Jetforms,
the customer would like to print from PSM to the printer.
Questions:
5) For the data that will flow directly from PSM to a printer, the
customer is interested in "the reliable delivery of data" and wants to
"check in only one place to verify whether or not data has arrived".
This seems like exactly what PSM is supposed to do, but not having any
experience with PSM I'd like to get you to verify this.
6) For data that, for whatever reason, needs to flow through an NT
queue, would there be any benefit at all for routing the data through
PSM? Would we be able to use PSM to track the print job at least part of
the way through the print process? Any benefits for trouble shooting?
Would there be any increase of reliability by sending the data through
PSM prior to sending the data to NT?
Answer:
5) The PSM GUI provides an "Event Log" button which will pop up a
window and allow you to select the servers you wish to monitor (or
all servers). If you are not using the GUI, the events are logged
in each respective servers errorlog (i.e. /var/pd/super1/error.log).
There will be an error log for each server as well as for psmd.
6) There would be little benefit to routing the jobs through PSM. The
only "tracking" that could be done is from PSM to the NT server and
that is all. We would have no way of knowing if the NT server
successfully printed the job or not. From a trouble shooting stand
point, you would have iptrace capability on AIX, so under certain
circumstances, that could be helpful. One other concern is header
information. It wouldn't surprise me if some header information was
lost somewhere along the way. Since there would be potentially 3 lpd
"hops", the user name could become lpd and the filename a temporary
filename.
Thanks for using WWQ&A.
S e a r c h - k e y w o r d s:
psm windowsNT jetforms bsd aix unix nt windows hacmp lpr lpd iptrace
WWQA: ITEM: RTA000145260 ITEM: RTA000145260
Dated: 11/1998 Category: PSMAIX
This HTML file was generated 99/06/24~12:43:36
Comments or suggestions?
Contact us