Chris Mason wrote:
When VTAM is doing a GETMAIN for more buffers, all using VTAM need to wait
for that GETMAIN to complete. Not a problem, but observable ...
The trick here is to tune the dynamic buffering parameters. You can set the
affected buffer pool to have sufficient buffers to be able
The 'tuning column' is number of times Expanded.
In a message dated 10/8/2012 6:44:33 A.M. Central Daylight Time,
elardus.engelbre...@sita.co.za writes:
DISPLAY NET,BFRUSE command *after* the morning rush happens.
--
To all interested in this topic, particularly, for the first topic, Norbert
Friemel (for Gilbert Saint-Flour), Phil Smith and Edward Jaffe
Would someone be so kind as to explain why the two flavours for the operation
of IND$FILE are tied to Control Unit Terminal (CUT) type and Distributed
John
Does that mean that when I use IND$FILE with a 64x128 screen it sends 8192
bytes at a time ?
I think so. But remember that those 8192 bytes must include any require 3270
protocol overhead bytes.
Assuming my analysis of the significance of *not* being able to use Write
Structured
Mike
Here is Microsoft's suggestions for increasing the speed, from 2004.
http://support.microsoft.com/kb/125881
The first point to make here is that the configuration which applies to Bill
Gates's SNA Server (BizTalk Server Host Integration Server these grandiloquent
days) is probably *not*
Elardus
When VTAM is doing a GETMAIN for more buffers, all using VTAM need to wait
for that GETMAIN to complete. Not a problem, but observable ...
The trick here is to tune the dynamic buffering parameters. You can set the
affected buffer pool to have sufficient buffers to be able to cater
Chris Mason wrote:
'Maximizing the SNA RU size reduces end-to-end acknowledgments at the 3270
application level.'
This is just common sense.
Thanks. Agreed.
In order to illustrate the point I'm assuming you have to send 10K of data and
the flow control parameters are such that each unit of
Mike
Well, I did the research for you!
- According to Gilbert Saint-Flour's web page, IND$FILE dates from 1983.
- According to RFC 765, FTP dates from 1980.
Much older program.
Neither much nor older as 1980 comes before 1983!
Chris Mason
On Wed, 19 Sep 2012 07:16:25 -0500, Mike Schwab
Dave
... does anyone know what protocol is used for file transfers by the ISPF
Workstation Agent (WSA.EXE)?
I guess the folk who created it do!
Perhaps the question you wanted to ask is the following:
Would someone please describe what protocols are used by the ISPF WSA?
Well, I have
chrisma...@belgacom.net (Chris Mason) writes:
Well, I did the research for you!
- According to Gilbert Saint-Flour's web page, IND$FILE dates from 1983.
- According to RFC 765, FTP dates from 1980.
re:
http://www.garlic.com/~lynn/2012m.html#37 Why File transfer through TSO
IND$FILE
: Why File transfer through TSO IND$FILE is slower than
TCP/IP FTP ?
Does that mean that when I use IND$FILE with a 64x128 screen it sends
8192 bytes at a time ?
Regards,
Thomas Berg
___
Thomas Berg Specialist AM/SMS SWEDBANK AB
On my systems FTP is still faster than IND$FILE, but let me just throw out
a little tidbit for consideration.
On my own Personal Communications sessions that use IND$FILE for transfers,
I found a very noticeable increase in speed if I defined my connections
using the numeric dotted IP address for
On Fri, Sep 21, 2012 at 6:37 PM, Roger Bolan rogerbo...@gmail.com wrote:
On my systems FTP is still faster than IND$FILE, but let me just throw out
a little tidbit for consideration.
On my own Personal Communications sessions that use IND$FILE for transfers,
I found a very noticeable
edja...@phoenixsoftware.com (Edward Jaffe) writes:
You've described the old CUT-mode interface. Somewhere around the
early 1980s, DFT mode was introduced. It does not encode the data, use
a screen to send it, or any of that. It simply wraps the binary data
in a 3270 structured field envelope
Scott ford wrote:
'Maximizing the SNA RU size reduces end-to-end acknowledgments at the 3270
application level.'
That's called pacing, vpacing
Oh, yes. Thanks, now all make sense to me! Many thanks for helping out!
I appreciate it very much!
:-D
Groete / Greetings
Elardus Engelbrecht
Lots of nooks and crannies. If you're so inclined === d net,bfruse will
show different pools in use and any dynamic expansion. Lots of tuning
opportunities. Got it going pretty good and another app dies 'cause we don't
support vpacing!
The old AT3270 had a really good manual. For some
Try larger blocksizes.
Much older program.
On Wed, Sep 19, 2012 at 6:34 AM, Tsai Laurence ltsai85...@gmail.com wrote:
Dear listers ,
as the subject, test file transfer through TSO IND$FILE TCP/IP FTP , and
found TSO IND$FILE is much slower than FTP. Any idea why ?
Regards,
Laurence
--
It just is. Funky protocol.
--
Sent from my mobile phone. Please excuse my brevity.
Charles
Tsai Laurence ltsai85...@gmail.com wrote:
Dear listers ,
as the subject, test file transfer through TSO IND$FILE TCP/IP FTP , and
found TSO IND$FILE is much slower than FTP. Any idea why ?
Regards,
:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Why File transfer through TSO IND$FILE is slower than TCP/IP
FTP ?
Dear listers ,
as the subject, test file transfer through TSO IND$FILE TCP/IP FTP ,
and
found TSO IND$FILE is much slower than FTP. Any idea why ?
Regards,
Laurence
Mike,
I use 32k on Qws3270p ...
Scott ford
www.identityforge.com
On Sep 19, 2012, at 8:16 AM, Mike Schwab mike.a.sch...@gmail.com wrote:
Try larger blocksizes.
Much older program.
On Wed, Sep 19, 2012 at 6:34 AM, Tsai Laurence ltsai85...@gmail.com wrote:
Dear listers ,
as the subject,
Tsai Laurence wrote:
as the subject, test file transfer through TSO IND$FILE TCP/IP FTP , and
found TSO IND$FILE is much slower than FTP. Any idea why ?
Blocksize, 3270 screen size limits and overhead of TSO between VTAM as well as
IND$FILE which needs to work with the emulator handling
On Wed, 19 Sep 2012 07:39:13 -0500, McKown, John wrote:
ftp does not go through as many transitions. Basically, there is an IP
connection to a server which write directly to a file. The only encode/decode
is if you do an ASCII translation. With TSO IND$FILE, you must encode and
decode all your
Tsai,
to speed up IND$FILE, have you tried to add BUFNUM=32 (for example) in the
VTAMLST LOCAL node for TSO terminals??
Hope this helps.
Paolo Cacciari
Senior IT Specialist - Certified
Dear listers ,
as the subject, test file transfer through TSO IND$FILE TCP/IP FTP ,
and
found TSO
://www.identityforge.com/
From: Thomas Berg thomas.b...@swedbank.se
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Wednesday, September 19, 2012 10:03 AM
Subject: SV: Why File transfer through TSO IND$FILE is slower than TCP/IP FTP ?
Does that mean that when I use IND$FILE
, 2012 9:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SV: Why File transfer through TSO IND$FILE is slower than
TCP/IP FTP ?
Does that mean that when I use IND$FILE with a 64x128 screen it sends
8192 bytes at a time ?
Regards,
Thomas Berg
Laurence
John McKown gave you a rather long explanation.
A shorter one - from which John's points can be derived - is that the TSO
session supporting the 3270 data stream was *never* designed to support file
transfer. It was designed to support conversational interaction with an end
user
Mike
Much older program.
You might like to research that point. I'm not at all sure that it is. Also I
wouldn't necessarily conclude that age necessarily answered Laurence's question.
Chris Mason
On Wed, 19 Sep 2012 07:16:25 -0500, Mike Schwab mike.a.sch...@gmail.com wrote:
Try larger
Paolo
Hope this helps.
Only if Laurence Tsai is using an ICC at the point of concatenation and only
for inbound transfers.
When an ICC is used, the VTAM statement defining the secondary LU is a LOCAL
statement. When the SNA-oriented TELNET server supplied with the IP component
of z/OS
On 09/19/2012 07:39 AM, McKown, John wrote:
ftp does not go through as many transitions. Basically, there is an IP
connection to a server which write directly to a file. The only encode/decode
is if you do an ASCII translation. With TSO IND$FILE, you must encode and
decode all your data into
I'm quite sure that it has to do with screen buffer sizes, including whether
the connection is CUT or DFT. I've been at sites where a multi-megabyte
IND$FILE takes seconds, and at others where 100K takes minutes.
Of course since it's doing terminal I/O, and lots of it, the network and VTAM
and
File transfer through TSO IND$FILE is slower than TCP/IP
FTP ?
Dear listers ,
as the subject, test file transfer through TSO IND$FILE TCP/IP FTP
, and found TSO IND$FILE is much slower than FTP. Any idea why ?
Regards,
Laurence
Here is Microsoft's suggestions for increasing the speed, from 2004.
http://support.microsoft.com/kb/125881
On Wed, Sep 19, 2012 at 7:58 AM, Scott Ford scott_j_f...@yahoo.com wrote:
Mike,
I use 32k on Qws3270p ...
Scott ford
www.identityforge.com
On Sep 19, 2012, at 8:16 AM, Mike Schwab
32 matches
Mail list logo
