On z/OS 3.1, I just created a 3 line member in my FB/80 CNTL PDS as:
000000000000000
1111111111
2222222222
That's unnumbered, so there's nothing but spaces to the right. I
downloaded to my PC with ASCII turned off but CRLF turned on. IND$FILE
(and the terminal emulator) gave me this:
0000000 f0f0 f0f0 f0f0 f0f0 f0f0 f0f0 f0f0 f040
0000020 4040 4040 4040 4040 4040 4040 4040 4040
0000040 4040 4040 4040 4040 4040 4040 4040 4040
0000060 4040 4040 4040 4040 4040 4040 4040 4040
0000100 4040 4040 4040 4040 4040 4040 4040 4040
0000120 0d0a f1f1 f1f1 f1f1 f1f1 f1f1 4040 4040
0000140 4040 4040 4040 4040 4040 4040 4040 4040
0000160 4040 4040 4040 4040 4040 4040 4040 4040
0000200 4040 4040 4040 4040 4040 4040 4040 4040
0000220 4040 4040 4040 4040 4040 4040 4040 4040
0000240 4040 0d0a f2f2 f2f2 f2f2 f2f2 f2f2 4040
0000260 4040 4040 4040 4040 4040 4040 4040 4040
0000300 4040 4040 4040 4040 4040 4040 4040 4040
0000320 4040 4040 4040 4040 4040 4040 4040 4040
0000340 4040 4040 4040 4040 4040 4040 4040 4040
0000360 4040 4040 0d0a 1a00
So that's EBCDIC still, but with CRLF's at the end of each line.
Interestingly, the line ends come at the very end of each 80 byte
record, not after the last non-space character like the ASCII option
trimming does.
Here's the same member downloaded with both ASCII and CRLF options:
0000000 3030 3030 3030 3030 3030 3030 3030 300d
0000020 0a31 3131 3131 3131 3131 310d 0a32 3232
0000040 3232 3232 3232 320d 0a1a
So like Gil mentioned, CRLF without ASCII would allow text file
conversion to be done on the PC side while still giving the record
splits. In other words, we might have a possible use for this :)
This was using a particular terminal emulator I happen to have on my
Windows PC. Other emulators may have different results.
ALCON!
On 1/17/2025 1:16 PM, Phil Smith III wrote:
"ALCON"?
This is uploading TO z/OS. That's why the question: there's no "records" per se
in a bytestream, so there's no clear way to decide where to put them.
See the replies by Charles and Michael. Charles notes that it's not *adding*
the CR/LF, it's *honoring* them, and Michael posited a plausible (if
exceedingly rare) use case.
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
Harry Wahl
Sent: Friday, January 17, 2025 3:38 PM
To: [email protected]
Subject: Re: File transfer question
ALCON:
"My question is: Can you devise a scenario where a binary transfer "with CR/LF"
makes sense?"
What if you are sending a file with a special purpose code page that FTP does
not (and possibly cannot) support to a Windows or whatever file system? A file
which is known not to contain any CR or LF characters (not that unusual). The
records could be of undefined length and still need the CRLF from FTP on the
other side for the Windows file system to separate them.
Or, for that matter, a file whose data isn't intended for display or any
intra-record parsing, such as engineering or scientific data (e.g. CNC or the
output of many types of lab equipment). Typically, such data has a predefined
set of possible values that doesn't contain CRs or LFs. The CRLF is still
necessary on the Windows (or whatever) side because a way to separate records
is still necessary.
I can think of a lot more examples.
Harry
________________________________
From: IBM Mainframe Discussion List <[email protected]> on behalf of Steve
Horein <[email protected]>
Sent: Thursday, January 16, 2025 7:06 PM
To: [email protected] <[email protected]>
Subject: Re: File transfer question
How's this?
"No."
On Thu, Jan 16, 2025 at 4:02 PM Bob Bridges <
[email protected]> wrote:
Ten replies not counting the OP's, and NOT A SINGLE responder actually
addressed his question?!
---
Bob Bridges, [email protected], cell 336 382-7313
/* Whoever gossips to you will gossip about you. */
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On
Behalf Of Phil Smith III
Sent: Thursday, January 16, 2025 11:24
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
----------------------------------------------------------------------
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
