× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Dear Mike,

Rodney Johnson works at IBM Rochester and he is the technical team lead for
the OS/400 spool. He frequently answers printing related questions that are
posted into the usenet newsgroup comp.sys.ibm.as400.misc. He unfortunately
only has time to read one IBM midrange related techical forum so he is not a
subscriber to midrange-l. I sometimes forward printing related questions
posted in midrange-l to him for a response and then echo his response back
into midrange-l.

His thoughts about your question are included below:

Paul, As to the customer's questions:

It is my thought that:
   LPR/LPD method (*IP remote outq) is easier to configure than *SNA
   LPR/LPD method is easier to debug than *SNA
   LPR/LPD method is done with spooled file once the send is complete,
   where as *SNA has to wait for confirmation from destination system
   (protocol difference)
   *SNA probably has better through put than *IP because of the protocol
   differences
   Both provide the same level of attribute and data retention for spooled
   files sent
   Even though it is not considered the preferred method (we would rather
   see users try SNMP printer driver where ever possible), *IP can go
   directly to a printer *SNA cannot.
   *IP method allows the data to be transformed, *SNA method does not


Regards,
Rodney A. Johnson
rodaj@us.ibm.com
AS/400 Spool Technical team lead
(507) 253-7925
t/l 553-7925

HTH

Best Regards,

/Paul
--
Paul Tykodi
National Product Manager
LCI-Intermate US, Inc.

p: 603.431.0606 x115
f: 603.436.6432
paul@intermate-us.com
www.intermate.com

>Subject: Printer Pass-thru (TCP/IP vs. SNA)
>To: midrange-l@midrange.com
>From: Mike.Crump@saint-gobain.com
>Date: Tue, 13 Aug 2002 12:09:29 -0500
>Reply-To: midrange-l@midrange.com
>
>We currently have an environment where we move print from a corporate
>AS/400 to ours via a high speed multi-protocol connection.  We use the
>process lightly and have always configured the remote OUTQ's as SNA.
>However, recently we have had numerous issues with SNA traffic on our
>network.  So far the network gods have admitted to no problems but we now
>routinely have SNA outages that are in the hours range.  It's not really
>mine to solve so I've stayed out of it and this is not the intent of my
>question.
>
>Shortly, hourly plant payroll checks will be coming across this connection.
>And I can smell the disaster coming.  I have no true vested interest in the
>SNA connection.  We used it starting years ago because it was what we used
>locally and everyone was comfortable with it.  I've not pushed migration of
>certain applications towards TCP/IP since our network supports both
>(normally quite well) and the telcom people haven't pushed the issue.
>Therefore, I only want to take the task on if it is necessary.
>
>My question is that I'd like to know what issues exist if any between
>sending print from AS/400 to AS/400 via TCP/IP vs. SNA?  The print being
>transferred from them is plain vanilla (standard SCS).  I'm sure that there
>are a few people that have changed their method from SNA to TCP/IP and
>would like to get their perspective on performance, functionality,
>ownership, attributes, etc.
>
>
>
>Michael Crump
>Saint-Gobain Containers
>1509 S. Macedonia Ave.
>Muncie, IN  47302
>(765)741-7696
>(765)741-7012 f
>(800)428-8642
>
>mailto:mike.crump@saint-gobain.com



As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.