pmattes
commented
1 year ago I have a couple of questions.
First, why are you running 4.0 for a new installation? The current version is 4.2. I don't think this is the issue, but it seems a little odd.
Second, are you actually running x3270 (on Linux), or wc3270 on Windows?
Third, would it be possible for you to capture a data stream trace of a failed transfer? With a large transfer, it might get a little large, but it would be very helpful (especially the end, where the error occurs).
I might take you up on your offer for VM access. All I have here for VM testing is VM/370 SixPack under Hercules.
Previous release V3.6ga4. Newer version V4.0ga12. I transfer up to VM large binary software distribution files that, once uploaded, will be submitted as jobs to VSE. With V3.6, I found that some transfers would repeatably fail at the same point if I was using an ICC 3270 server on multiple z-boxes (z10, 114, z12). But, if I connected to the 3270 server running in VM, the problem did not occur. I just moved to a new laptop and installed V4.0. Today, I tried a large binary transfer (via ICC) and it failed. I then tried it connecting to z/VM and it also failed. I did another test on my old laptop with V3.6. It failed via ICC but worked when using VMs 3270 server. In the past, I chalked it up to a problem with the ICC software on the z-box, but now that it started failing when connecting to z/VM, I now think it is an x3270 problem. The transfer fails with "TRANS13 Error writhing file to host: file transfer canceled". When it works, it gives me the number of bytes and indicates it used "dtf" mode. With a little set-up, I can give you both the binary file I am transferring and access to my VM system for testing, if needed. Tony Thigpen