[87] in Enterprise Print Delivery Team
Re: Barr Systems, Inc. via CDB
daemon@ATHENA.MIT.EDU (David F. Lambert)
Wed Feb 23 08:01:46 2000
Message-Id: <10002231303.AA08454@MIT.EDU>
Date: Wed, 23 Feb 00 07:42:32 EST
From: "David F. Lambert" <LAMBERT@mitvma.mit.edu>
To: Scott Kelley <Scott.Kelley@barrsys.com>
Cc: Enterprise Printing Delivery Project Team <printdel@MIT.EDU>
In-Reply-To: Your message of Mon, 21 Feb 2000 14:40:48 -0500
Hi Scott,
Let me see if I can fill in a few of the blanks.
1) Re mainframe connectivity. We run two Logical Partitions (LPARs)
on our ES9121-570. Each partition has at least one TCP/IP connection
to our campus backbone. We also use SNA but not over our TCP/IP
network.
2) Re IPDS routing options. I'm not sure what this means. We could
grab the output files from the AFP Spool File Conversion Machine (SFCM).
However, this sounds like a question better handled by a VM/AFP expert
which I'm not. Can you get an answer to this question from someone
at Barr who's more knowledgable regarding VM/AFP?
3) Re IPDS transforms. The ability to transform to/from IPDS has some
attraction but we're not sure we'll need/want this ability yet. At
least three other options appear to be possible for us.
1) Implement printers which handle multiple types of internal print
datastreams such as Xerox.
2) Using a tool like Barr or IPM would allow us to manage both AFP
and Postscript queues and their respective printers via a single
interface. We could continue to use the legacy AFP printers
for the legacy print queues and the network attached printers
for the Postscript queues.
3) Manage the legacy AFP and new Postscript queues & printers
with different tools. This is the model today and we're looking
for something better.
Are there other options for handling two or more datastream types?
What are the dis/advantages of each option from Barr's perspective?
-Dave
ps. I'm cc:'ing the printing project's email list on this note.
On Mon, 21 Feb 2000 14:40:48 -0500 Scott said:
>Dear Dave,
>
>Thank you for giving Barr Systems, Inc. an opportunity to review your
>requirements and recommend a solution.
>
>I have a few questions based on what I gleaned from the two web links you
>sent me:
>
>1. Do you have any other connectivity to the mainframe besides bus & tag?
>TCP/IP or SNA through a FEP or router, etc?
>2. If you do have other connection options to the mainframe can you route
>your IPDS through one of those connections?
>3. Do you need to perform data transforms to IPDS? From IPDS?
>
>I believe from the information in your Enterprise Printing Strategies web
>links that some of these questions have not been answered at the present
>time. I ask them because we only provide IPDS passthrough capability over
>SNA and TCP/IP for channel attached IPDS printers. We do have a module that
>can transform fully composed AFP files to any Windows NT printer, however.
>But we do not have any IPDS spooling capabilities.
>
>Another area I wanted to touch on was your desire to move toward "saving
>more trees" down the road. We have recently partnered with a couple of
>firms that provide us with new functionality that may be of interest to you.
>
>
>One company provides electronic report management by converting reports from
>a multiplicity of data-streams into PDF. The PDFs are indexed and stored
>unaltered in COLD storage for retrieval by clients. This could fulfill your
>"Report on Demand" option mentioned in your I/T Discovery document in the
>Market Analysis section. You can perform the archiving and indexing on
>existing printed report data-streams and make them available upon demand
>thus reducing or eliminating production printing of these reports.
>
>With the SAP reports and perhaps some other reports, we have partnered with
>a company that does data mining of ASCII print-streams. This software
>provides the capability to extract data from routine reports and redirect
>the data to other applications for analysis or reformated printing.
>
>To conclude, most of the rest of your host connectivity needs, as well as
>print management needs, can be accommodated with the Barr Enterprise Print
>Server. The following modules would be needed to accommodate all
>connectivity needs: the BARR/PRINT TCP/IP module, the BARR/PRINT 390 module
>and either the BARR/NJE or the BARR/PRINT CHANNEL modules. The BARR/NJE or
>BARR/PRINT CHANNEL modules provide mainframe connectivity. The BARR/PRINT
>TCP/IP is a Line Print Daemon emulation for receiving print data from the
>network. Finally, the BARR/PRINT 390 module is your bus and tag connection
>to your production printers. If you need the IPDS passthrough capability
>for the BARR/PRINT 390 you will need to add the IPDS over SNA or IPDS over
>TCP/IP as required.
>
>I just wanted to touch base with you and respond to your initial inquiry to
>keep the dialog going. I am sure a number of questions will arise. Please
>feel free to contact me for any input be it technical or sales oriented. I
>will be happy to do the leg-work necessary to answer any technical questions
>I can't field directly.
>
>Scott Kelley
>Sales Consultant, Barr Systems, Inc.
>800-BARR-SYS ( +1-352-491-3100 ( Fax +1-352-491-3141 ( sales@barrsys.com
>
>
>
>-----Original Message-----
>From: David F. Lambert [mailto:LAMBERT@mitvma.mit.edu]
>Sent: Thursday, February 17, 2000 7:56 AM
>To: Scott Kelley
>Subject: Re: Barr Systems, Inc. via CDB
>
>Hi Scott,
>
>Here are the two promised links - one for our completed printing
>"discovery" project and the other for the active printing "delivery"
>project. Also, you'll find some topic areas we'll want to discuss
>with Barr below too.
> -Dave
>
>http://web.mit.edu/is/discovery/enter-print/
>http://web.mit.edu/is/delivery/enterprint/
>
>Discussion topics for vendors:
> o review of functionality
> o end user interface
> o operator interface
> o scriptability (commandline vs GUI interface issue)
> o queue definition and management interface
> o security (several aspects)
> o forms overlay capabilities (ex: W2)
> o delegation of authority; what functions, granularity, etc.
> o printer integration; print drivers, printers, tightly coupled?, etc
> o internal architecture
>
