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
