v3.0.0-rc2 vs. v2.2.32
Moderator: Project members
v3.0.0-rc2 vs. v2.2.32
My project requires sending a data file, followed by a trigger file, to the same location on the mainframe, which is MVS on z/OS. The trigger file is a group of server commands that requires "SITE FILETYPE=JES" to be sent before the trigger file itself. The following is my experience:
1. v2.2.32 can't handle sending the trigger file properly, as I received everytime a message of "user not authorized" so that upload failed. v3.0.0-rc2 works fine in sending the same trigger file, after I put the server command in sitemanager.xml.
2. v3.0.0-rc2, however, can't handle a normal connection to MVS without this command line of "SITE FILETYPE=JES". When using v2.2.32, I can always see the remote directory on MVS as a result of LIST command after login. v3.0.0-rc2 by itself run LIST and LIST -a successively, but still there's no remote directory showing up. The consequence is that I can't double-click any file to transfer.
If necessary, I can provide debug info. Before that, is it possible that I didn't something wrong while setting up v3.0.0-rc2? I hope I don't have to use v2.2.32 to send my data file and v3.0.0-rc2 for trigger.
Thanks very much.
1. v2.2.32 can't handle sending the trigger file properly, as I received everytime a message of "user not authorized" so that upload failed. v3.0.0-rc2 works fine in sending the same trigger file, after I put the server command in sitemanager.xml.
2. v3.0.0-rc2, however, can't handle a normal connection to MVS without this command line of "SITE FILETYPE=JES". When using v2.2.32, I can always see the remote directory on MVS as a result of LIST command after login. v3.0.0-rc2 by itself run LIST and LIST -a successively, but still there's no remote directory showing up. The consequence is that I can't double-click any file to transfer.
If necessary, I can provide debug info. Before that, is it possible that I didn't something wrong while setting up v3.0.0-rc2? I hope I don't have to use v2.2.32 to send my data file and v3.0.0-rc2 for trigger.
Thanks very much.
Re: v3.0.0-rc2 vs. v2.2.32
Yes please.gimmely wrote:If necessary, I can provide debug info.
Set debug level to 3 and enable raw directory listing. Next restart FileZilla and connect to the server.
Here's a section of debug in v3.0.0-rc2:
Command: LIST
Trace: CTransferSocket::OnConnect
Trace: CFtpControlSocket::OnReceive()
Response: 550 No data sets found.
Trace: CFtpControlSocket::TransferParseResponse()
Trace: CFtpControlSocket::ResetOperation(2)
Trace: CControlSocket::ResetOperation(2)
Trace: CFtpControlSocket::SendNextCommand(2)
Trace: CFtpControlSocket::ListSend(2)
Trace: CFtpControlSocket::SendNextCommand(0)
Trace: CFtpControlSocket::TransferSend(0)
Command: PASV
Trace: CFtpControlSocket::OnReceive()
Response: 227 Entering Passive Mode (155,180,212,40,10,157)
Trace: CFtpControlSocket::TransferParseResponse()
Trace: CFtpControlSocket::TransferSend(0)
Command: LIST -a
Trace: CTransferSocket::OnConnect
Trace: CFtpControlSocket::OnReceive()
Response: 550 No data sets found.
Trace: CFtpControlSocket::TransferParseResponse()
Trace: CFtpControlSocket::ResetOperation(2)
Trace: CControlSocket::ResetOperation(2)
Trace: CFtpControlSocket::SendNextCommand(2)
Trace: CFtpControlSocket::ListSend(2)
Trace: Server seems to support LIST -a
Trace: CFtpControlSocket::ResetOperation(0)
Trace: CControlSocket::ResetOperation(0)
Status: Directory listing successful
Command: LIST
Trace: CTransferSocket::OnConnect
Trace: CFtpControlSocket::OnReceive()
Response: 550 No data sets found.
Trace: CFtpControlSocket::TransferParseResponse()
Trace: CFtpControlSocket::ResetOperation(2)
Trace: CControlSocket::ResetOperation(2)
Trace: CFtpControlSocket::SendNextCommand(2)
Trace: CFtpControlSocket::ListSend(2)
Trace: CFtpControlSocket::SendNextCommand(0)
Trace: CFtpControlSocket::TransferSend(0)
Command: PASV
Trace: CFtpControlSocket::OnReceive()
Response: 227 Entering Passive Mode (155,180,212,40,10,157)
Trace: CFtpControlSocket::TransferParseResponse()
Trace: CFtpControlSocket::TransferSend(0)
Command: LIST -a
Trace: CTransferSocket::OnConnect
Trace: CFtpControlSocket::OnReceive()
Response: 550 No data sets found.
Trace: CFtpControlSocket::TransferParseResponse()
Trace: CFtpControlSocket::ResetOperation(2)
Trace: CControlSocket::ResetOperation(2)
Trace: CFtpControlSocket::SendNextCommand(2)
Trace: CFtpControlSocket::ListSend(2)
Trace: Server seems to support LIST -a
Trace: CFtpControlSocket::ResetOperation(0)
Trace: CControlSocket::ResetOperation(0)
Status: Directory listing successful
My last reply was from logging in FileZilla without any SITE command in sitemanager.xml.
This one is from having SITE FILETYPE=JES in sitemanager.xml:
Command: SITE FILETYPE=JES
Trace: CFtpControlSocket::OnReceive()
Response: 200 SITE command was accepted
Status: Connected
Trace: CFtpControlSocket::ResetOperation(0)
Trace: CControlSocket::ResetOperation(0)
Status: Retrieving directory listing...
Trace: CFtpControlSocket::SendNextCommand(0)
Command: PWD
Trace: CFtpControlSocket::OnReceive()
Response: 257 "'CVRDFTP.'" is working directory.
Trace: CFtpControlSocket::ResetOperation(0)
Trace: CControlSocket::ResetOperation(0)
Trace: CFtpControlSocket::SendNextCommand(0)
Trace: CFtpControlSocket::ListSend(0)
Trace: CFtpControlSocket::SendNextCommand(0)
Trace: CFtpControlSocket::TransferSend(0)
Command: TYPE I
Trace: CFtpControlSocket::OnReceive()
Response: 200 Representation type is Image
Trace: CFtpControlSocket::TransferParseResponse()
Trace: CFtpControlSocket::TransferSend(0)
Command: PASV
Trace: CFtpControlSocket::OnReceive()
Response: 227 Entering Passive Mode (155,180,212,40,11,87)
Trace: CFtpControlSocket::TransferParseResponse()
Trace: CFtpControlSocket::TransferSend(0)
Command: LIST -a
Trace: CTransferSocket::OnConnect
Trace: CFtpControlSocket::OnReceive()
Response: 125 List started OK
Trace: CFtpControlSocket::TransferParseResponse()
Trace: CFtpControlSocket::TransferSend(0)
Trace: CTransferSocket::OnClose
Trace: CTransferSocket::TransferEnd(1)
Trace: CFtpControlSocket::TransferEnd()
Trace: CFtpControlSocket::OnReceive()
Response: 250 List completed successfully.
Trace: CFtpControlSocket::TransferParseResponse()
Trace: CFtpControlSocket::ResetOperation(0)
Trace: CControlSocket::ResetOperation(0)
Trace: CFtpControlSocket::SendNextCommand(0)
Trace: CFtpControlSocket::ListSend(0)
Trace: CFtpControlSocket::ResetOperation(0)
Trace: CControlSocket::ResetOperation(0)
Status: Directory listing successful
This one is from having SITE FILETYPE=JES in sitemanager.xml:
Command: SITE FILETYPE=JES
Trace: CFtpControlSocket::OnReceive()
Response: 200 SITE command was accepted
Status: Connected
Trace: CFtpControlSocket::ResetOperation(0)
Trace: CControlSocket::ResetOperation(0)
Status: Retrieving directory listing...
Trace: CFtpControlSocket::SendNextCommand(0)
Command: PWD
Trace: CFtpControlSocket::OnReceive()
Response: 257 "'CVRDFTP.'" is working directory.
Trace: CFtpControlSocket::ResetOperation(0)
Trace: CControlSocket::ResetOperation(0)
Trace: CFtpControlSocket::SendNextCommand(0)
Trace: CFtpControlSocket::ListSend(0)
Trace: CFtpControlSocket::SendNextCommand(0)
Trace: CFtpControlSocket::TransferSend(0)
Command: TYPE I
Trace: CFtpControlSocket::OnReceive()
Response: 200 Representation type is Image
Trace: CFtpControlSocket::TransferParseResponse()
Trace: CFtpControlSocket::TransferSend(0)
Command: PASV
Trace: CFtpControlSocket::OnReceive()
Response: 227 Entering Passive Mode (155,180,212,40,11,87)
Trace: CFtpControlSocket::TransferParseResponse()
Trace: CFtpControlSocket::TransferSend(0)
Command: LIST -a
Trace: CTransferSocket::OnConnect
Trace: CFtpControlSocket::OnReceive()
Response: 125 List started OK
Trace: CFtpControlSocket::TransferParseResponse()
Trace: CFtpControlSocket::TransferSend(0)
Trace: CTransferSocket::OnClose
Trace: CTransferSocket::TransferEnd(1)
Trace: CFtpControlSocket::TransferEnd()
Trace: CFtpControlSocket::OnReceive()
Response: 250 List completed successfully.
Trace: CFtpControlSocket::TransferParseResponse()
Trace: CFtpControlSocket::ResetOperation(0)
Trace: CControlSocket::ResetOperation(0)
Trace: CFtpControlSocket::SendNextCommand(0)
Trace: CFtpControlSocket::ListSend(0)
Trace: CFtpControlSocket::ResetOperation(0)
Trace: CControlSocket::ResetOperation(0)
Status: Directory listing successful
Did it and debug info is below:
Command: LIST
Trace: CTransferSocket::OnConnect
Trace: CFtpControlSocket::OnReceive()
Response: 550 No data sets found.
Trace: CFtpControlSocket::TransferParseResponse()
Trace: CFtpControlSocket::ResetOperation(2)
Trace: CControlSocket::ResetOperation(2)
Trace: CFtpControlSocket::SendNextCommand(2)
Trace: CFtpControlSocket::ListSend(2)
Trace: CFtpControlSocket::ResetOperation(0)
Trace: CControlSocket::ResetOperation(0)
Status: Directory listing successful
Command: LIST
Trace: CTransferSocket::OnConnect
Trace: CFtpControlSocket::OnReceive()
Response: 550 No data sets found.
Trace: CFtpControlSocket::TransferParseResponse()
Trace: CFtpControlSocket::ResetOperation(2)
Trace: CControlSocket::ResetOperation(2)
Trace: CFtpControlSocket::SendNextCommand(2)
Trace: CFtpControlSocket::ListSend(2)
Trace: CFtpControlSocket::ResetOperation(0)
Trace: CControlSocket::ResetOperation(0)
Status: Directory listing successful
What are trigger files?
According to your log, there's nothing wrong. Your server reports in an exotic, nonstandard way that the current directory is empty.
(If I had the chance to meet one of the MVS developers, I would slap him with common sense carved into granite. Supporting MVS is a major PITA.)
According to your log, there's nothing wrong. Your server reports in an exotic, nonstandard way that the current directory is empty.
(If I had the chance to meet one of the MVS developers, I would slap him with common sense carved into granite. Supporting MVS is a major PITA.)
I noticed that in v3.0.0 the site manager information is not stored within the Filezilla.xml file in any longer. This means that when using Filezilla on a USB drive, You lose all site data when moving from PC to PC. Why was this function removed/changed? This is the main reason I use Filezilla. I guess it's back to v2.2.32.
http://filezilla.sourceforge.net/forum/ ... 3910#13910
check my post after your 1st in that topic. And don't flood forum ...
check my post after your 1st in that topic. And don't flood forum ...
[quote="botg"]What are trigger files?
According to your log, there's nothing wrong. Your server reports in an exotic, nonstandard way that the current directory is empty.
(If I had the chance to meet one of the MVS developers, I would slap him with common sense carved into granite. Supporting MVS is a major PITA.)[/quote]
(I just want to continue my original thread.)
First things first, I'd love to be able to provide such an opportunity to you. But on second thought, I think it'd be better not to so as to get over with this PITA.
Now, to answer your question, the trigger file in my case is a pure text file with lines of commands for MVS to trigger a JCL(? - I think) job to start processing the data file that is FTP'd before the trigger file. This line, SITE FILETYPE = JES, which I believe you know means the file that follows to be FTP'd should contain commands to be executed on MVS, is between sending the data file and trigger file.
Not bothering or being bothered by MVS, I'm wondering why v3.0.0-rc2 behaves differently from v2.2.32. Yes, the directory on MVS is empty. But, v2.2.32 works as 1) it can show the empty directory and 2) I can double click the local file to send over. v3.0.0-rc2 doesn't do either, not to mention those return values as 2 in ResetOperation and SendNextCommand. It's weird that I'd not double-click or highlight a local file.
If it's only due to some against-common-sense settings on MVS, I'm thinking if it means that v2.2.32 is more "tolerant" to handle it than v3.0.0-rc2.
I consider FileZilla is a very good product. So, please don't take my questions as negative or looking-for-trouble comments.
Thanks.
According to your log, there's nothing wrong. Your server reports in an exotic, nonstandard way that the current directory is empty.
(If I had the chance to meet one of the MVS developers, I would slap him with common sense carved into granite. Supporting MVS is a major PITA.)[/quote]
(I just want to continue my original thread.)
First things first, I'd love to be able to provide such an opportunity to you. But on second thought, I think it'd be better not to so as to get over with this PITA.
Now, to answer your question, the trigger file in my case is a pure text file with lines of commands for MVS to trigger a JCL(? - I think) job to start processing the data file that is FTP'd before the trigger file. This line, SITE FILETYPE = JES, which I believe you know means the file that follows to be FTP'd should contain commands to be executed on MVS, is between sending the data file and trigger file.
Not bothering or being bothered by MVS, I'm wondering why v3.0.0-rc2 behaves differently from v2.2.32. Yes, the directory on MVS is empty. But, v2.2.32 works as 1) it can show the empty directory and 2) I can double click the local file to send over. v3.0.0-rc2 doesn't do either, not to mention those return values as 2 in ResetOperation and SendNextCommand. It's weird that I'd not double-click or highlight a local file.
If it's only due to some against-common-sense settings on MVS, I'm thinking if it means that v2.2.32 is more "tolerant" to handle it than v3.0.0-rc2.
I consider FileZilla is a very good product. So, please don't take my questions as negative or looking-for-trouble comments.
Thanks.
I think this is due to the case FZ3 handles transfer connections.
By default, FileZilla uses separate connections to the server for browsing and for file transfer. Thus, all raw ftp commands you enter only work for the browsing connection and not the transfer connection.
As workaround, you can limit the number of connections to 1 in the Site Manager, then FileZilla 3 will reuse the browsing connection for the transfers.
By default, FileZilla uses separate connections to the server for browsing and for file transfer. Thus, all raw ftp commands you enter only work for the browsing connection and not the transfer connection.
As workaround, you can limit the number of connections to 1 in the Site Manager, then FileZilla 3 will reuse the browsing connection for the transfers.
Some updates:
1. I downloaded v3rc3 and the results were the same as v3rc2.
2. I checked sitemanager.xml and found the following:
<MaximumMultipleConnections>0</MaximumMultipleConnections>
Since it didn't work and I suspected "0" would mean unlimited, I changed it to "1". But, the results remained the same.
I don't think changing this setting in v3rc2 would have some fundamentally different results.
Should we just "blame" MVS? :) Or, is it worth it to make v3 work the same as v2.2.32 ONLY on this subject?
1. I downloaded v3rc3 and the results were the same as v3rc2.
2. I checked sitemanager.xml and found the following:
<MaximumMultipleConnections>0</MaximumMultipleConnections>
Since it didn't work and I suspected "0" would mean unlimited, I changed it to "1". But, the results remained the same.
I don't think changing this setting in v3rc2 would have some fundamentally different results.
Should we just "blame" MVS? :) Or, is it worth it to make v3 work the same as v2.2.32 ONLY on this subject?