[137] in Enterprise Print Delivery Team
Answers to our follow up questions for Moore
daemon@ATHENA.MIT.EDU (David F. Lambert)
Wed Mar 15 08:37:08 2000
Message-Id: <10003151335.AA18817@MIT.EDU>
Date: Wed, 15 Mar 00 08:28:09 EST
From: "David F. Lambert" <LAMBERT@mitvma.mit.edu>
To: Enterprise Printing Delivery Project Team <printdel@MIT.EDU>
Gang,
Below you'll find Moore's response to our follow up questions. I think
there's some good info below. So, please review their comments. I've
indicated to Moore that we're pleased with the work and that they may
consider their work complete. We can always ask a few more questions
later if we so choose. Mary Ellen, it would probably be useful to add
the URL references mentioned below to our web pages.
-Dave
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hi Dave,
Here are our responses to your questions. Some of these may require some
additional discussion at your discretion
1. What are Moore's opinions regarding i-data, Jetforms & Print Exchange?
(a few sentences on each product would be appreciated)
A: We are a bit confused by the question, as you have not mentioned in
what context you would consider each of these products.
Let me at least briefly talk about each and what, if any role, we
feel they would play in an enterprise solution for MIT.
i-data - i-data is primarily a manufacturer of connectivity products.
These products also perform some language translation or printer
emulation capability to other hosts. The one product that may make
some
sense for MIT might be there new SafeCom product.
This provides a "slide your card & enter your PIN" level of security
to release your print job. However, based on our knowledge, it works
in conjunction with one or more of their connectivity products.
For instance, you might connect an HP 8100 with EasyCom 10/100 Xpress
along with the SafeCom box. MIT does not seem to have a connectivity
issues. Therefore, other than the SafeCom product might provide a
good solution for distributed MICR check printing, we don't see a fit.
JetForm - JetForm touts integration with SAP and other systems and for
the most part, it works well under certain situations. Moore is the
largest reseller of JetForm systems in the US, and quite frankly, we
don't see a particularly good fit, other than perhaps for check
printing.
Secondly, we did not note any complaints from users regarding the lack
of
formatting capability by their existing systems. Only the ability to
control paper tray pulls and other printer control features not
supported by UNIX were noted as issues.
Print Exchange - The only product I can think of that you may be
referring to here, would be Xerox's PrintXchange. This is a new
product
that was designed to work in the DocuTech world, not the transactional
print world. We do not se a fit here at all.
2. Do other companies basically ignore the issue of un-encrypted
sensitive print files traveling over their intranets?
A: Quite frankly, we have not seen a great deal of encryption being used
other than between sites. Those systems are usually using hardware-
based solutions at the network level. i-data's SafeCom may be of some
use here for MICR check printing but we don't see much use beyond
that.
I would think that anyone able to intercept a print job from non check
application, could possibly get at the data in SAP or the DW anyway.
One new technology that is beginning to be used in this area is the
use of Virtual Private Networks. (VPN's)
3. We could manage the legacy and Postscript/network attached printer
worlds with separate tools. What are the real advantages
to managing these two worlds with a single tool such as IPM?
You mentioned one or two specific benefits on Pg 4 of your report -
are there other key benefits?
A: In actuality, you manage your two worlds today with two separate
tools,
the mainframe and APS. Each of them does a great job at managing it's
world as it was designed to do.
If using transform technology to simplify how you print production
versions of reports generated in Postscript to AFP printers still
makes sense, then moving to one central print management system is
key to your success. However, remember we are not replacing APS, only
managing those PRODUCTION NETWORK jobs that require AFP printing.
This doesn't mean that a central print management solution can't be
taught to share information and job management with APS and
vice-versa.
Some of the more obvious benefits of a central system, such as IPM,
would be the ability to:
- Queue jobs for production printers as you do today
- Match class & Form Type between jobs & printers
- Start and stop jobs as needed
- Reprint and job retention capability
- Remote management of the system
- Java enabled
- Robust
- Simple to use
- Transforms PS to AFP transparently
- Support IBM and other printer manufacturers
- Will support the Xerox IPS series emulating either a 3825 or 3827
4. If we decided to manage the two worlds separately, what would
be Moore's top two or three recommended solutions for managing the
Postscript/network attached world - Dazel & EasySpooler? Do
either of these products handle AFP print files or AFP printers (either
channel of network attached)?
A: We would still recommend either IPM or BARR to manage the mainframe
printing.
If APS is not a player or an option, then BARR or EasySpooler for the
network jobs.
Dazel is a very comprehensive system as well, but rather expensive the
last
time I checked. Solimar still has the best transforms in the business
outside of
the IPM transform. They can even go the other way (AFP to PS).
Here are some links for you if you do not have them.
http://www.barrsys.com/product/beps/default.asp
http://www.solimarsystems.com/
http://www.dazel.com/products/OutputServer.html
http://www.easyspooler.com/ezspooler.html
The following link is an interesting article at SunWorld written by
one of our customers, The American Kennel Club. Chuck Musciano writes
about
printing in the UNIX world as compared to the mainframe world.
He discusses the pitfalls and the benefits from some tools that will
help - EasySpooler
and IPM.
http://www.sunworld.com/sunworldonline/swol-01-1999/swol-01-print_p.html
5. For what period of time would you predict your proposed architectural
model to be viable?
A: We installed IPM at the American Kennel Club two years ago and it is
working
very well for them. In there case, I am very confident that IPM will
continue
to be the best solution for at least the next 5 years or more.
Remember, IBM is constantly improving the product still, and is about
to formally
launch their NT version. IBM is putting all of there print management
eggs
in the AIX and NT baskets. There has been no further development in
printing
under any of the IBM mainframe OS's for at least the last 4 years that
I know of.
6. Does the transformation process require much processor overhead?
A: In all of the application benchmark testing we have done to date, we
have
not noticed any significant CPU hit. However, the number, complexity
and
frequency of your PS application should be considered as part of the
sizing and configuration of the RS/6000.
I will ask one of our Integration Consultants to run a 50 to 100 page
job
to our IPM/3160 in both AFP and PS and have him document the
processing
time difference between both jobs and we'll let you know.
7. Should we be concerned about resolution issues if we transform
600 DPI PostScript output to 240 DPI AFP (current 3827)?
A: I would ask IBM if they are supporting 600 dpi transform input to the
3827.
If IPM does support 600 dpi input and 240 dpi output, I would believe
that
SAP and DW reports would probably print fine at 240 dpi. If there are
graphics,
charts or graphs, then it would probably be considered unsuitable.
I'm certain that this would not be a problem on the 3160's.
8. It appears we would have three options for the central
printing of differing datastream types with the IPM/Barr solution -
transformation to a single datastream type, provide multiple
types of printers (i.e. PostScript & AFP), or implement central
printers which can handle multiple types of datastreams such
as Xerox. What are the key dis/advantages of these three approaches?
A: Actually, in the case of Xerox, I would recommend that you use just
the IPS
version of the printer and let IPM send AFP or Postscrip transformed
to AFP
to the Xerox and IBM printers. If desired, IPM can also manage
straight
Postscript jobs to HP's.
You are going to have at least two print data languages (PDL's) no
matter
what you do. The recommendation we would make is that you keep it to
just two!
Use AFP for production printing and Postscript for user/department
printing.
This limits the technical expertise needed as well to just two PDL's.
Both
PDL's can be managed well by whatever system you choose to manage
them.
The disadvantage of the Xerox switchable system is just that. You
must
reboot the system to print jobs from the other. It will spool PS jobs
while
printing AFP jobs, but as you know, IPDS cannot be spooled. So when
printing
PS jobs, it cannot spool AFP jobs. The Xerox NPS version
(Postscript/PCL),
also has a command line interface that is not particularly user
friendly at
this point. The IPS version, which emulates either a 3825 or 3827,
has an
easy to use GUI. It will also print native 240 dpi streams or convert
them to
300 dpi. 240 and 300 dpi streams are also digitally interpolated to
600 dpi
in the case of the 4635 IPS or DP96 IPS systems. This engine prints
at
600 dpi regardless of the input.
As I'm sure you know Dave, you can always be assured that IBM will
have a
family of AFP printers available. As well as we could each bet a
weeks pay
on HP keeping Postscript alive for the foreseeable future. Therefore,
we
feel that AFP and Postscript are two PDL's you can hang your hat on
for
some time to come.
I hope that I have answered your questions to the degree you were looking
for.
If not, and you would like clarification or would like to discuss these any
further
please let me know.
Best Regards,
Bob
