You're assuming IND$FILE is behind this. I expect it is, in this case, but it doesn't need to be. BINARY makes perfect sense if it's FTP behind the scenes. Just sayin'. One might also argue that to folks more familiar with FTP, BINARY also makes more sense than ASCII.
The whole file transfer area is and always has been a mess! -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Charles Mills Sent: Friday, January 17, 2025 12:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: File transfer question I think the problem is that the option is confusingly named. The question is "should IND$FILE translate the data from ASCII to EBCDIC? Yes or No." The word "binary" implies data that might well contain all 256 possible 8-bit values. That might not be the case at all. Perhaps it is all valid ASCII characters that you simply do not want translated from ASCII to EBCDIC, as @Michael suggests, or perhaps the data is already in EBCDIC. The actual IND$FILE option is ASCII, which is either specified or not specified. The keyword "binary" is an invention of the emulator authors. Charles On Thu, 16 Jan 2025 21:35:35 -0500, Phil Smith III <li...@akphs.com> wrote: >Ah, thanks, Charles (and Michael). That makes a LOT more sense. Still, it's >rare enough that having the option there so prominently seems odd. I'd think >it would be so rare that a dialog saying "Are you sure?" with a "Don't show >this again" might be worthwhile. Of course that requires more tests, so maybe >not... > >-----Original Message----- >From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On >Behalf Of Schmitt, Michael >Sent: Thursday, January 16, 2025 8:15 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: File transfer question > >My guess is the use case is that you have an ASCII text file, with ASCII >CR/LF, and you want to upload it as ASCII, but have the CR/LR determine the >records. I can think of one example right now: uploading .JSON files. When >I’ve used them in Enterprise COBOL, they have to be ASCII. > >So the Binary option is because you don’t want it to convert ASCII to EBCDIC, >but the CR/LF is because you don’t have fixed length data; it really is a text >file. > >From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on >behalf of Phil Smith III <li...@akphs.com> >Reply-To: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> >Date: Thursday, January 16, 2025 at 10:24 AM >To: "IBM-MAIN@LISTSERV.UA.EDU" <IBM-MAIN@LISTSERV.UA.EDU> >Subject: File transfer question > >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 lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with >the message: INFO IBM-MAIN > > > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, send >email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, send >email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
