We send our fixes and other materials in xmi format. The client should upload it as Binary,fb,80, 3120. No crlf. The blocking is decided by the leech and block size.
ITschak *| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux and IBM I **| * *|* *Email**: [email protected] **|* *Mob**: +972 522 986404 **|* *Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|* בתאריך יום ה׳, 16 בינו׳ 2025 ב-18:24 מאת Phil Smith III <[email protected]>: > A customer just had a problem uploading some service we'd released. It was > an XMIT file, and they did transfer it as binary F 80, but TSO RECEIVE was > failing. After some tinkering and comparing screenshots of the file, they > eventually found that they had "the CR/LF option" checked in their > emulator, which they called "the Rocket emulator" (I suspect that is/was > BlueZone). They sent a screenshot that shows the file transfer options: > Binary vs. text, plus checkboxes for Append and CR/LF. > > My question is: Can you devise a scenario where a binary transfer "with > CR/LF" makes sense? I can't even think how it would decide where to put > them in--it's just a byte stream! The only linends are whatever the native > platform uses, but if it's binary those wouldn't seem to me to be > meaningful. And of course a binary file could well have those bytes in the > data. > > Maybe I'm missing something obvious [as usual]? > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
