Since you're failing at a certain size, it's your mainframe space command.
A mainframe file can only have 16 extents, 1 primary allocation and 15 secondary allocations. If the disk pack is full or nearly full, you might not get your primary allocation.
In your current allocation, you're asking for 500 primary tracks and 15 * 500 secondary tracks, for a total of 8,000 tracks. A track will hold either 2 or 3 blocks of 26,000 bytes, depending on the disk drive track size. If you specify a block size of 0, the IBM operating system will calculate the most efficient block size.
A bit of math indicates you've allocated for 208,000 records (worst case).
You probably should specify your space in cylinders, and have a small primary and larger secondary. Something like:
ftpClient.sendSiteCommand("SPACE=(CYL,(30,300),RLSE)");
If your mainframe shop insists on you specifying tracks, try this:
ftpClient.sendSiteCommand("SPACE=(TRK,(450,4500),RLSE)");
I made both numbers divisible by 15, because if I recall correctly, a cylinder contains 15 tracks.
Edited to add:
I just found the IBM FTP commands page on the IBM web site. It appears you have to send each part of the space command separately, just like the DCB command.
ftpClient.sendSiteCommand("TR");
ftpClient.sendSiteCommand("PRI=450");
ftpClient.sendSiteCommand("SEC=4500");
Best Answer
Why on Earth do you think they don't have bugs?
IBM has a vast support infrastructure for bug reporting and resolution (PMRs, APARs and PTFs), which is heavily used.
Mainframe software which hasn't been touched for many years will certainly be well understood (at least in terms of its idiosyncrasies) and will likely have had many bugs either fixed or worked around. All of the new stuff being developed nowadays actually plans for a certain number of bugs and patches from GA (general availability) to at least GA + 36 months. In fact, an ex-boss of mine at IBM used to baulk at being forced to provide figures for planned bugs with the line: "We're not planning to have any bugs".
The mainframe espouses RAS principles (reliability, availability and serviceability) beyond what most desktop hardware and software could ever aspire to - that's only my opinion of course, but I'm right :-)
That's because IBM knows all too well that the cost of fixing bugs increases a great deal as you move through the development cycle - it's a lot cheaper to fix a bug in unit testing than it is to fix one in production, in terms of both money and reputation.
There's a great deal of effort and cost expended on only releasing bug-free software but even they don't get it right all the time.