Classification: Confidential Zloty's or USD? <G>
-----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Radoslaw Skorupka Sent: Friday, January 17, 2025 3:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: File transfer question [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] My $0.02 Transfer between mainframe (z/OS) and distributed systems has never been an issue or mess. It is simple homework to do. 1. ASCII-EBCDIC translation. IMHO obvious. Note, we do *not* consider national codepages. It will be mentioned later. 2. Record oriented dataset <-> byte oriented file. This is crucial. It is like a shadow. Shadow is two-dimensional, so looking at shadow we don't know third dimension of a sculpture. This is dataset -> file. Simple. However the opposite, means file -> dataset lacks third dimension! So we have to provide it manually. Manually, because there is no relevant metadata. For XMIT it is really simple. You have to download it from z/OS with *no* translation. Binary. And you will loose "third dimension" - RECFM,LRECL. Note this. When uploading you have to provide the lost dimension: RECFM=FB,LRECL=80. Provide it in your PCOMM, Nexus or other 3270 emulator. FB 80 and *no* translation. That also mean no special meaning for CR LF or any other byte combination. And that's all. However when you want to transfer text file, instead of XMIT, you have to switch on EBCDIC to ASCII translation. Or rather mainframe codepage to PC codepage. For Poland we have CP870 on EBCDIC side and... several codepages (over 10!) on PC side. The most common are ISO8859-2, CP1250 and CP852, the rest is obsolete. In that case you have to use proper built-in translation table in FTP, your own table in IND$FILE or your own codepage translator application on PC or mainframe site. Unfortunately IBM does not provide such tool. I wrote one, customizable, however it was over 20 years ago, Turbo-Pascal application and it does not work in Win 64 environment. What's sad, after so many years it is still an exercise to solve. The is no simple wizard or set of tools available. -- Radoslaw Skorupka Lodz, Poland W dniu 17.01.2025 o 21:00, Phil Smith III pisze: > You're assuming IND$FILE is behind this. I expect it is, in this case, but it > doesn't need to be. BINARY makes perfect sense if it's FTP behind the scenes. > Just sayin'. One might also argue that to folks more familiar with FTP, > BINARY also makes more sense than ASCII. > > The whole file transfer area is and always has been a mess! > > -----Original Message----- > From: IBM Mainframe Discussion List<IBM-MAIN@LISTSERV.UA.EDU> On > Behalf Of Charles Mills > Sent: Friday, January 17, 2025 12:15 PM To:IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: File transfer question > > 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 with the message: INFO IBM-MAIN ::DISCLAIMER:: ________________________________ The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ________________________________ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
