Not disagreeing with Charles at all, his response in this thread
triggered more thoughts on this end.
As I said privately to the OP, there are really only two options when
transferring files between mainframe op sys (MVS, VM, VSE, TPF) and PC
(Windoze, Mac, Linux): binary and plain text. Anything else really needs
to be considered a special case. "text" should be ASCII (or a variant*)
with CR/LF, "binary" means no translation and no record interpolation.
*ASCII is actually a 7-bit character set. But we commonly use
ISO-8859-1, which maps almost perfectly with CP1047 on the EBCDIC side.
More recently, the "ASCII" side uses UTF-8, but that's a rabbit trail we
don't chase ... yet.
Now ... if someone really wants to pull down ASCII records and tack-on
CR/LF, let em. But that's the exception.
The point here is the _default details_ behind "text" and "binary"
modes. By default, "text" implies do translate and do interpolate
records at CR/LF, and, by default, "binary" implies no translation and
no record markers or interpolation.
Phil, if your customer doesn't know this, you should add a paragraph or
three to your maint doc. This isn't rocket surgery.
-- R; <><
On 1/17/25 12:14 PM, Charles Mills wrote:
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
tolists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with the message:
INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
tolists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
-- R; <><
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
