View previous topic :: View next topic
|
Author |
Message |
sushanth bobby
Senior Member
Joined: 29 Jul 2008 Posts: 1020 Location: India
|
|
|
|
I have a simple question. In my company, i can download a PDF file of 20MB in less than 4 minutes. But, when I download a file from mainframe which is around 10MB it takes nearly 20-40minutes. Can I know, the reason for this? |
|
Back to top |
|
|
superk
Global Moderator
Joined: 26 Apr 2004 Posts: 4652 Location: Raleigh, NC, USA
|
|
|
|
Let's try to be clear with what you're asking.
Are you saying that, using the same download method from the same mainframe server to the same client system, that the 20MB PDF (i.e. binary) file transfers in less than 4 minutes, but the 10MB text file (i.e. ASCII text) transfers in 20-40 minutes?
What do your network engineers have to say? |
|
Back to top |
|
|
Bill Dennis
Active Member
Joined: 17 Aug 2007 Posts: 562 Location: Iowa, USA
|
|
|
|
Are you comparing to a PDF download from the Internet?
If you are using IND$FILE for downloads, try using FTP instead. It may be faster. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Download times will depend on network configuration, mainframe system load, and configuration of the network, routers, TCP/IP, FTP, and so forth -- lots of potential problem areas. For just one example, if your mainframe task is running as a discretionary workload under WLM, it would only get CPU time when nothing else needed it -- which could really delay the download. 10 MB in 40 minutes is about 4K per second -- which is extremely slow for Ethernet connections.
We're using a standard Ethernet connection on the OSA for our internal network and I consistently get 6 to 10 MB per second download and upload speeds -- it rarely takes more than 3 minutes to transfer an entire CD to the mainframe. Internet transfers depend on the connections and the other side of the FTP but it's not unusual to get 1 MB per second |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10872 Location: italy
|
|
|
|
the question might be simple, but the wording does not help anybody to help You ....
case 1 20 Mbytes 4 minutes from Your company
seems clear, You have a connection to Your company network
case 2 10 Mbytes 20 minutes from mainrame...
please clarify what do You mean by mainframe
and what kind of connection You have to mainframe ????
maybe the connection to Your company is an internal network ???
if by mainframe You mean ... I just do not know what to guess |
|
Back to top |
|
|
sushanth bobby
Senior Member
Joined: 29 Jul 2008 Posts: 1020 Location: India
|
|
|
|
Hi Guyz,
Sorry for not being clear.
When iam downloading a PDF file from internet, it takes less than 4 mins.
But, when i am downloading a DATASET from mainframe. IND$FILE method as dennis said. In this method, it is taking nearly 30-40mins.
Till now my thinking was, MAINFRAME character codeset is EBCDIC and PC windows is ASCII. So, when i download a file from mainframe to pc. I thought Character Conversion are all happening. Thats why its downloading slow.
I have a doubt from what robert said, when you SUBmit a FTP job then only WLM comes into action, right.
Sushanth |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10872 Location: italy
|
|
|
|
t' s just an IND$FILE issue...
transmit/receive thru 3270 emulation is just a tweak of the 3270 protocol
with forced encapsulation in a 3270 stream
and it is SLOOOWWWWW ! |
|
Back to top |
|
|
sushanth bobby
Senior Member
Joined: 29 Jul 2008 Posts: 1020 Location: India
|
|
|
|
So, is there any other method to download a file, i mean a dataset from mainframe other than IND$FILE and FTP.
Sushanth |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
WLM comes into play whether you submit a job or not -- one possible reason for the slowness is that your TSO session doing the IND$FILE is being moved into a discretionary service class due to being a long-running TSO task. Discretionary WLM work only gets CPU time when nothing else wants the CPU.
Suggestion: on your PC, bring up a command window and type in FTP <your mainframe> (either DNS name or IP address). Sign on with your user id and password, then GET the mainframe file and see how long it takes. FTP server tasks usually run at a nice priority so you might get better response time by running this way.
And I've done some testing and see no major difference in throughput of FTP using text or binary transfers -- the conversion process is pretty fast. |
|
Back to top |
|
|
sushanth bobby
Senior Member
Joined: 29 Jul 2008 Posts: 1020 Location: India
|
|
|
|
Robert,
I just did what you suggested. And the results were WOW.
Today morning i downloaded a file from mainframe IND$FILE style. It took nearly took 30 minutes to download. And the size was 12MB. I tried to download that same file using FTP as you SUGGESTED and size is just 4mb. And it took less than 3mins to download. So, i thought, some of the data might have been truncated while downloading. I use this file to make excel reports. So, i did the same excel procedure. The thing is no records were truncated, everything is similar. What makes me wonder is 'Why the size difference ?'.
I could save a lot of time by this method, ROBERT.
Can i continue with this method, will there be any problem ?
THANK YOU VERY MUCH
Sushanth |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Glad to hear the speed is there -- I suspect discretionary service class is to blame. The size difference may be due to IND$FILE retaining trailing spaces while FTP drops them, but I really don't know for sure. There is an option in FTP to keep or drop trailing blanks.
Continuing with the FTP method shouldn't cause any problems. If you're looking at a production system, though, I'd recommend getting systems to provide a network server you can FTP to so the FTP job can be driven from the mainframe side, not from your PC (what happens if you go on vacation -- does the FTP just not happen?) That allows your scheduling system to run the job and takes you completely out of the processing loop. |
|
Back to top |
|
|
|