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

Another update:

A colleague in our shop who knows the communications stuff was surprised by
slow transmissions as described earlier in this thread.  He introduced me to
the SAVRSTOBJ command, to use in place of FTP.  I don't remember seeing this
one before, but the command appears to have been around since at least V3R2.
This IBM command has a lot of the SAVOBJ parameters.  It saves the specified
objects, transmits to a remote AS/400, and restores the objects, all in one
step.  Why the heck am I using FTP?

SAVRSTOBJ took 8 minutes to run the whole thing for two files totalling
43.6MB.  Remember that this includes the SAVe, the transmission, and the
ReSTore.  The FTP for these two same files took 12.4 minutes when I ran it
last week; add more time for the save and the restore.  To compare apples to
apples, I redid the FTP, timing both the SAVOBJ and the FTP on the remote
box and then timing the restore on the target box.  The SAVOBJ took 2.5
minutes, the FTP took 7.7 minutes (almost twice as fast this time), and the
RSTOBJ took 7 seconds, basically the same time to run the SAVRSTOBJ.

So, I don't get it.  Why would anyone choose using FTP to transmit objects
across AS/400s over SAVRSTOBJ?

> -----Original Message-----
> From: Bale, Dan [SMTP:DBale@Lear.com]
> Sent: Thursday, May 04, 2000 11:46 AM
> To:   'MIDRANGE-L@midrange.com'
> Subject:      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
> 
        < big snip >
+---
| 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
+---