(off topic, I'm sorry)
Usually I use €0.02, however we don't have EUR, it's still PLN.
And "my 0.02" is American saying, we (rarely) use "3 grosze" (3 cents).
BTW: there is PLN and there was PLZ.
PLZ is old currency, rarely used in common language, since it was
deprecated 30 years ago. 1PLN=10000PLZ.
1PLN is approx. 4USD.
Regarding IND$FILE... nothing to say. ;-)
--
Radoslaw Skorupka
Lodz, Poland
W dniu 17.01.2025 o 22:54, Allan Staller pisze:
Classification: Confidential
Zloty's or USD? <G>
-----Original Message-----
From: IBM Mainframe Discussion List<[email protected]> On Behalf Of
Radoslaw Skorupka
Sent: Friday, January 17, 2025 3:42 PM
To:[email protected]
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<[email protected]> On
Behalf Of Charles Mills
Sent: Friday, January 17, 2025 12:15 PMTo:[email protected]
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<[email protected]> 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<[email protected]> On
Behalf Of Schmitt, Michael
Sent: Thursday, January 16, 2025 8:15 PMTo:[email protected]
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<[email protected]> on
behalf of Phil Smith III<[email protected]>
Reply-To: IBM Mainframe Discussion List<[email protected]>
Date: Thursday, January 16, 2025 at 10:24 AM
To:"[email protected]" <[email protected]>
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 [email protected] with the message: INFO IBM-MAIN
