× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On Thu, Jun 29, 2017 at 9:22 AM, John Yeung <gallium.arsenide@xxxxxxxxx>
wrote:

On Thu, Jun 29, 2017 at 10:09 AM, Charles Wilt <charles.wilt@xxxxxxxxx>
wrote:
I updated from 2.7.12 to 2.7.13...

So far, the issue hasn't reoccurred..

I'm glad it seems to have been resolved. But...

I noticed in the changelog for 2.7.13:

- Issue #27211: Fix possible memory corruption in io.IOBase.readline().

That issue was actually fixed in 2.7.12. (The changelog goes back
quite a ways, well past just the latest point release. It's easy to
miss the version header separating the releases when you're scanning
the whole thing.) And I don't think it would manifest in a way that
reorders lines but is otherwise clean.


​Well..may have spoke to soon...

One of my team mates is still seeing it...even with 2.7.13...



On Thu, Jun 29, 2017 at 9:41 AM, Charles Wilt <charles.wilt@xxxxxxxxx>
wrote:
connection.storlines('STOR ' + ibmi_file, open(source_file.fullpath,
'rb'))

Based on your description of the symptoms, and looking at the above
line of Python code, my best guess is that you were seeing some kind
of I/O buffering effect.

I guess you don't need any workarounds at the moment, but it might be
handy to keep some ideas in your pocket in case this comes up again.
Some things to try:

- Use mode 'r' instead of 'rb' when opening the file. (Plain 'r' is
the default and can be omitted.) The significance of this being that
in some contexts, buffering is different when dealing with text mode
versus binary mode.


​doesn't storlines() require 'rb'?
https://stackoverflow.com/questions/17777745/python3-ftplib-storlines-error



- Fiddle with the explicit buffering setting on the open(). You can
choose 0 for unbuffered, 1 for line-buffered, or a positive number to
specify a desired byte size.


​May try that...​
​though it doesn't appear that line-buffered work with 'rb'



- Try to eliminate operating-system-level buffering by loading all the
data into a StringIO (memory file) object first, and send from that.


might look at that...



- Rework the process so that you can use FTP's binary mode (via the
storbinary() method) instead. This is of course more involved, and
there are several very different approaches that fall under this
umbrella (for example, you could translate the data to EBCDIC in
Python and continue trying "direct" FTP, or you could zip up the data
and unzip on the i, etc.) but still not especially difficult, and
worth a try if the simpler measures fail.


​Given that we're sending to a PF-SRC...I wouldn't expect FTP binary mode
to work...don't we need the ASCII<-->EBCDIC conversion done by the FTP
server on the i?



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.