HMC / I/O definition requires 80 bytes per line (Conner ran into thins in https://blog.share.org/Technology-Article/i-just-bought-an-ibm-z890-now-what )
On Sun, Jan 19, 2025 at 7:03 AM Radoslaw Skorupka <00000471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: > > 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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
