RE: Correlating *SAVF "records" to FTP job I/O count

An update:

Well, had another opportunity to FTP a save file between two AS/400s.  I ran
the FTP interactively so that I could see the running number of "bytes
transferred" and attempt to correlate that to the job's I/O count on the
save file.  On the AS/400 from which the FTP PUT was running, the job showed
an average of approximately 4200 bytes per savefile I/O.  Out of curiosity,
I signed on to the AS/400 that was receiving the FTP'd save file, found the
job that was receiving it, and, lo & behold, the bytes per savefile I/O was
527.982, i.e., 528!!!!  So the I/O count on the receiving box is the number
of records in the save file!  This at least solves the immediate problem of
estimating the completion time of the transmission.

Still waiting to hear from the network group to see if they have any
resolutions for the slow transmissions.

- Dan Bale

> -----Original Message-----
> From: Patrick Townsend [SMTP:townsend@patownsend.com]
> Sent: Wednesday, May 03, 2000 4:26 PM
> To:   MIDRANGE-L@midrange.com
> Subject:      Re: Correlating *SAVF "records" to FTP job I/O count
> 
> Dan,
> 
> This is good information! The first thing it tells us is that there are
> a minimum of 5 hops (probably 4 routers and the end point) between the
> AS/400s. That's a lot. And they are not performing very well. I'd talk
> to the network folks to see if there is a more direct way of routing
> between the AS/400s. You can't know by looking at this, but its a good
> bet there are some efficiencies to be gained by adjusting the routing.
> 
> Some of these delays are pretty bad. Are you routing over the Internet?
> If so, you might want to consider a direct frame relay option, or a VPN
> solution from an Internet provider.
> 
> If you are not going over the Internet are you using frame relay
> services from a telco? If so, you might want to consider talking to them
> about guaranteed levels of service. 
> 
> HTH,
> Patrick
> -- 
> IBM AS/400 communications, FTP automation, and network security
> software and consulting services.
> 
> http://www.patownsend.com
> 
> "Bale, Dan" wrote:
> > 
> > (Patrick, also see my earlier reply to Rob)
> > 
> > O.k., so I do a tracert from my PC to the remote 400 in question and
> get:
> > 
> > Tracing route to as400.xxxxxxxx.xxxx.com [xx.x.xx.xx] over a maximum of
> 30
> > hops:
> >     1    10 ms   <10 ms   <10 ms  xx.x.xx.x
> >     2    10 ms    10 ms   <10 ms  xx.x.xxx.xxx
> >     3   100 ms   100 ms    40 ms  xx.x.xxx.x
> >     4    60 ms   130 ms    50 ms  xx.x.xx.x
> >     5    70 ms   180 ms    70 ms  xxxxxxx.xxxx.com [xx.x.xx.xx]
> > Trace complete.
> > 
> > I'm not sure what this is telling me.
> > 
> > TIA,
> > Dan Bale
> > 
> > > -----Original Message-----
> > > From: Patrick Townsend [SMTP:townsend@patownsend.com]
> > > Sent: Wednesday, May 03, 2000 1:36 PM
> > > To:   MIDRANGE-L@midrange.com
> > > Subject:      Re: Correlating *SAVF "records" to FTP job I/O count
> > >
> > >
> > > You can use the WRKCFGSTS and DSPLIND commands to look at the
> > > configurations. When TCP/IP is active on the AS/400 you will find a
> > > controller with a name like "ETHNET" and a device with a name like
> > > "ETHTCP" under the line description.
> > >
> > > How are the AS/400s networked? Ethernet, token ring, frame relay, ? If
> > > your PC is on the same network as the AS/400 you can use TRACERT to
> view
> > > a bit of information about the network topology. Start a DOS command
> > > window and use tracert with the remote AS/400 IP address:
> > >
> > >     tracert 1.1.1.1
> > >
> > > Tracert will show you the intermediate nodes in the network and
> provide
> > > you with some response times. Be aware that some routers may inhibit
> > > responses to Tracert so it cannot be assumed to be absolutely reliable
> > > in what it reports.
> > >
> > > Of course, if the AS/400 was a "real" computer it would have trace
> > > route... <ducking>...
> > >
> > > Patrick
> > >
> > > Patrick
> > >
> > > "Bale, Dan" wrote:
> > > >
> > > > Wow, what a difference!  I am unaware of the comm hardware involved
> here.  I
> > > > can tell you that they have a network of 30+ AS/400s.  FWIW, any of
> these
> > > > AS/400s can FTP to any other AS/400 in the network (I don't know if
> that
> > > > gives a clue as to the setup they're using).
> > > >
> > > > How can I tell what comm config is being used for FTP?
> > > >
> > > > TIA,
> > > > Dan Bale
> > > >
> > > > > -----Original Message-----
> > > > > From: Patrick Townsend [SMTP:townsend@patownsend.com]
> > > > > Sent: Wednesday, May 03, 2000 2:10 AM
> > > > > To:   MIDRANGE-L@midrange.com
> > > > > Subject:      Re: Correlating *SAVF "records" to FTP job I/O count
> > > > >
> > > > > Dan,
> > > > >
> > > > > I just transferred a large save file from the AS/400 to PC:
> > > > >
> > > > >     81792480 bytes transferred in 328.231 seconds. Transfer rate
> 249.191 KB/sec.
> > > > >
> > > > > I then transferred the same save file to another AS/400 on the
> same
> > > > > network (10, not 100):
> > > > >
> > > > >     81792480 bytes transferred in 127.947 seconds. Transfer rate
> 639.267KB/sec.
> > > > >
> > > > > I think you should be seeing better throughput! Have you talked to
> the
> > > > > network folks to see what they have to say?
> > > > >
> > > > > Patrick
> > > > >
> > > > >
> > > > > "Bale, Dan" wrote:
> > > > > >
> > > > > > That bugger took 3 hours and 40 minutes to transmit.  It was
> 59.7MB.  From
> > > > > > the log file:
> > > > > >
> > > > > >     61202064 bytes transferred in 12555.306 seconds. Transfer
> rate 4.875 KB/sec.
> > > > > >
> > > > > > The save file had 115,913 records.  115,913 * 528 = 61,202,064.
> The DSPOBJD
> > > > > > size was 59,785,216 (????).
> > > > > >
> > > > > > Using 1480 bytes per frame, would you calculate the number of
> puts as:
> > > > > >    1)  61,202,064 / 1480 = 41,352.7         *or*
> > > > > >    2)  1480 / 528 = 2 whole records per frame; 115,913 / 2 =
> 57,957
> > > > > > Based on the "guesstimate" that the number of puts was around
> 17,000 about
> > > > > > two hours into the job, I'm not sure either of these
> calculations work.
> > > > > >
> > > > > > I think I'm going to set up a test whereby I submit a batch job
> to do an FTP
> > > > > > and another batch job to do a DSPJOB OPTION(*OPNF) in a loop
> that runs every
> > > > > > 15 seconds and run some stats on the collected data to see if
> there's a
> > > > > > pattern I can use.
> > > > > >
> > > > > > Other suggestions are greatly appreciated!
> > > > > >
> > > > > > - Dan Bale
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Patrick Townsend [SMTP:townsend@patownsend.com]
> > > > > > > Sent: Monday, May 01, 2000 8:24 PM
> > > > > > > To:   MIDRANGE-L@midrange.com
> > > > > > > Subject:      Re: Correlating *SAVF "records" to FTP job I/O
> count
> > > > > > >
> > > > > > >
> > > > > > > Yes, 1496 bytes. Subtracting TCP/IP frame headers you are
> probably
> > > > > > > transferring 1480 bytes per frame. How long does it take to
> transfer a
> > > > > > > 58 meg save file? Just takes a few minutes here between AS/400
> and
> > > > > > > Windows NT PC.
> > > > > > >
> > > > > > > Patrick
> > > > > > >
> > > > > > > "Bale, Dan" wrote:
> > > > > > > >
> > > > > > > > What if I see that the Maximum Frame Size of the line
> description is 1496?
> > > > > > > > What does 1496 mean?  1496 bytes?  I don't have the
> authority to run a comm
> > > > > > > > trace here.  Not sure anyone else here would want to go
> through the bother.
> > > > > > > >
> > > > > > > > TIA,
> > > > > > > > - Dan Bale
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Patrick Townsend [SMTP:townsend@patownsend.com]
> > > > > > > > > Sent: Monday, May 01, 2000 3:15 PM
> > > > > > > > > To:   MIDRANGE-L@midrange.com
> > > > > > > > > Subject:      Re: Correlating *SAVF "records" to FTP job
> I/O count
> > > > > > > > >
> > > > > > > > > Dan,
> > > > > > > > >
> > > > > > > > > I believe the transfer record size of an FTP transfer will
> be controlled
> > > > > > > > > by the Maximum Frame Size of the line description. Save
> file record
> > > > > > > > > lengths are 528, but I believe FTP should send multiple
> records with
> > > > > > > > > each transfer. You can see what the AS/400 is doing by
> putting a
> > > > > > > > > communications trace on the line (STRCMNTRC). End the
> trace with
> > > > > > > > > ENDCMNTRC and then print it with PRTCMNTRC. There is a
> header for each
> > > > > > > > > TCP/IP frame, but you will get an idea of the size this
> way.
> > > > > > > > >
> > > > > > > > > Patrick
> > > > > > > > > --
> > > > > > > > > IBM AS/400 communications, FTP automation, and network
> security
> > > > > > > > > software and consulting services.
> > > > > > > > >
> > > > > > > > > http://www.patownsend.com
> > > > > > > > >
> > > > > > > > > "Bale, Dan" wrote:
> > > > > > > > > >
> > > > > > > > > > Is there a known, constant, record-blocking factor used
> when transmitting a
> > > > > > > > > > save file from one AS/400 to another via FTP?
> > > > > > > > > >
> > > > > > > > > > I am using FTP to transmit save files from plant boxes
> to the division box.
> > > > > > > > > > One I have running right now is 56MB.  The system
> operator is wondering how
> > > > > > > > > > much longer the FTP will run.  When I look at the job
> running FTP, it shows
> > > > > > > > > > the save file being transmitted as an open file (WRKJOB
> option 14) and shows
> > > > > > > > > > the I/O count at 12,417.  If I could correlate the save
> file's number of
> > > > > > > > > > records to the I/O count, I would be able to estimate
> the time remaining to
> > > > > > > > > > complete the transmission.
> > > > > > > > > >
> > > > > > > > > > RTFM?  Please point the way.
> > > > > > > > > >
> > > > > > > > > > - Dan Bale
> > > > > > >
> > > > > > > --
> > > > > > > IBM AS/400 communications, FTP automation, and network
> security
> > > > > > > software and consulting services.
> > > > > > >
> > > > > > > http://www.patownsend.com
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---