I was able to solve this problem. Before sending the Xmit datasets to the windows I preform on the Datasets a ADRDSSU RELEASE command. After performing the release command on the datasets I was able to return them to my z/os and then perform a succesfull receive .
On Mon, May 24, 2010 at 12:58 PM, Matan Cohen <matancohen...@gmail.com>wrote: > 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. > > -- 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
