After considering the issue again I decided to XMIT the dump datasets . so now i xmit the large dump and then send them to a windows FTP server . When trying to get them back . A receive on those file is finished but not successful. the Receive command allocate the Dump datasets but stop restoring after 1% usage of the dataset although it return a successful completion.
when entering this subject after succeeding to send a 2GB xmit datasets and getting them back successfully . I didn't imagine to myself it will not work with larger datasets. Any suggestion on How to over come this problem will be appreciate On Thu, May 6, 2010 at 7:46 AM, Paul Gilmartin <paulgboul...@aim.com> wrote: > On Wed, 5 May 2010 13:26:47 -0400, Bob Woodside wrote: > > >On Wednesday 05 May 2010, Paul Gilmartin wrote: > >> > >> I'm mystified. I use Filezilla server for SMP/E RECEIVE FROMNETWORK, > > > >I regularly use the FileZilla client on Windows, Linux, and Solaris > >workstations to connect to both the MVS and Unix sides of z/OS with no > >problem. > > > >However, there are a couple of caveats: > > > >You need an up to date version - older versions of the FileZilla indeed > >didn't understand the Unix side of z/OS. The oldest version I can find > >on any of my workstations id 3.0.1, which works fine. > > > >You need to specify the server type as Unix under the Advanced tab to > >access you Unix filesystem. > > > I don't use Filezilla client. Is it a GUI? I avoid GUI FTP clients. > FTP is broken as specified for GUI use: > > The format of the reply to LIST or NLST is not specified, and > dependent on the server system type. It was the assumption of > the design that the reply would be presented as text to a human > being at a terminal, who would be familiar with the conventions > of the server and know how to proceed. The RFC does not even > provide any uniform way to know which entries in the reply text > are directories and which are basefiles. Accordingly, the > GUI client must contain artificial intelligence to know the > conventions of each supported server. > > z/OS is particularly problematic in that the format of the reply > t > differs radically according to whether the PWD is: > > o A legacy data set prefix > > o A PDS directory > > o A Unix directory > > Further, it's possible to CD to a partial prefix that doesn't > even appear in the responses to LIST or NLST. > > This could be resolved by an extension to the FTP RFC specifying > a new command with a standard format for directory listings. But > there's too little demand to make this likely. And this should > be done with a newer, secure protocol such as SFTP that doesn't > transmit passwords in the clear and that doesn't require the > backsocked for data that's problematic for firewalls. > > -- gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- best regards, matan cohen MF System Administrator. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
