IMHO it works as expected.
When you want text you get text lines (not records). No remaining spaces
as it is not part of text. CRLF added during conversion from record to
line.
When you want the content 1:1 you usually don't expect CRLF, however you
can convert records to lines ended with CRLF. Note, CRLF is for *text*,
not for any file format on PC.
The question is how to transfer a dataset to file with EBCDIC->ASCII
conversion and spaces preservation. Very rare IMHO, however one may want
it. Why? Just to discuss the case on IBM-MAIN. ;-)
OK, for that case IND$FILE has no support, AFAIK. However you can
translate dataset from EBCDIC to ASCII. DatasetE -> DatasetA. Then
transfer it using CRLF and no translation. First step will translate
X'40' to X'20' and second step will transfer it with no changes except
CRLF added at end of record/line.
BTW: I use IND$FILE, but not for regular transfers or big files. IMHO it
is "quick & dirty" way to transfer some script or XMITted PDS. Ad hoc.
For production there is FTP or some MFT solution. With all the features
including CRLF, translation, translation tables, etc.
--
Radoslaw Skorupka
Lodz, Poland
W dniu 17.01.2025 o 23:12, Tom Brennan pisze:
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 <IBM-MAIN@LISTSERV.UA.EDU> On
Behalf Of Harry Wahl
Sent: Friday, January 17, 2025 3:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
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 <IBM-MAIN@LISTSERV.UA.EDU> on
behalf of Steve Horein <000005b0b4f1358b-dmarc-requ...@listserv.ua.edu>
Sent: Thursday, January 16, 2025 7:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU <IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: File transfer question
How's this?
"No."
On Thu, Jan 16, 2025 at 4:02 PM Bob Bridges <
00000587168ababf-dmarc-requ...@listserv.ua.edu> wrote:
Ten replies not counting the OP's, and NOT A SINGLE responder actually
addressed his question?!
---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
/* Whoever gossips to you will gossip about you. */
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
