Re: EBCDIC/ASCII - FTP

[Phil Smith III]

Sorry, now I'm confused again--the Bemer page was wrong, and you wanted to 
instead quote some random TSO page that doesn't mention ASCII or EBCDIC?

Not trying to take you to task, I'm honestly lost!

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Wednesday, May 8, 2024 2:30 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EBCDIC/ASCII - FTP

On Wed, 8 May 2024 12:05:26 -0400, Phil Smith III wrote:

>"I have seen this before"--what is "this"?
>
I believe he's referring to my citation of the classic rant:
<https://web.archive.org/web/20180513204153/http://www.bobbemer.com/P-BIT.HTM>

I copied the wrong UR.
<https://www.ibm.com/docs/en/zos/3.1.0?topic=processing-tso-command-environment>

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EBCDIC/ASCII - FTP

[Paul Gilmartin]

On Wed, 8 May 2024 12:05:26 -0400, Phil Smith III wrote:

>"I have seen this before"--what is "this"?
>
I believe he's referring to my citation of the classic rant:


I copied the wrong UR.


-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EBCDIC/ASCII - FTP

[Paul Gilmartin]

On Wed, 8 May 2024 12:05:26 -0400, Phil Smith III wrote:

>"I have seen this before"--what is "this"?
>
I believe he's referring to my citation of the classic rant:
<https://www.ibm.com/docs/en/zos/3.1.0?topic=processing-tso-command-environment>

>I'm curious about your assertion that ASCII/EBCDIC cannot translate cleanly. 
>With the right EBCDIC code page, we do this every day. The basic etoa() and 
>atoe() work fine, have not caused problems--and we care a lot about specific 
>characters, as we support "encrypt in EBCDIC, decrypt in ASCII" and vice versa 
>with Format-Preserving Encryption.
>  .
I agree emphatically.  Bijective translations exist between IBM037, IBM500, and
IBM1047 (is any of those not "EBCDIC"? ) and ISO8859-1.  I'm not sure how
"proprietary" applies".

Will the "real EBCDIC" please stand up!


>It seems clear that if IBM had inflicted (no scare quotes needed) ASCII as the 
>native encoding for S/360, there would have been more resistance. OTOH it's 
>not clear what realistic choice those customers would have had. There is 
>always the "If I have to do a conversion, I will at least look at 
>alternatives", and with IBM's fate hanging on the success of S/360, maybe that 
>would have been the proverbial straw; we'll never know.
>
>-Original Message-
>From: IBM Mainframe Discussion List  On Behalf Of 
>Tom Marchant
>Sent: Wednesday, May 8, 2024 11:37 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: EBCDIC/ASCII - FTP
>
>I have seen this before, and I am not persuaded. I find it interesting that 
>all of the references provided were written by Mr. Beemer himself, some of 
>them with another author.
>
>Perhaps, in hindsight it would have been better if IBM had made the
>System/360 an ASCII only machine. But at the time, ASCII was new and 
>relatively unknown. As it was, the market had generally rejected ASCII on 
>System/360, so the USASCII bit was removed with the introduction of
>System/370 in 1970.
>
>Both ASCII and EBCDIC are limited. ASCII, even more so because it is a
>7 bit code, though there are proprietary 8 bit extensions. No one knew in 1964 
>that Unicode would later be designed based upon ASCII.
>
>The claim that "A 1-to-1 translation between the two [ASCII and EBCDIC] 
>exists" is false.Each includes characters that are not defined in the other. 
>This has always been the case.
>
>If IBM had "inflicted" ASCII on its customers in 1964, would the
>System/360 have had the wide acceptance that it did? We will never know.
>
>According to "Architecture of System/360" 
>https://cpb-us-w2.wpmucdn.com/sites.gatech.edu/dist/8/175/files/2015/08/IBM-360.pdf
>
>
>The reasons against such exclusive adoption was the widespread use of the BCD 
>code derived from and easily translated to the IBM card code. To facilitate 
>use of both codes, the central processing units are designed with a high 
>degree of code independence, with generalized code translation facilities, and 
>with program-selectable BCD or ASCII modes for code-dependent instructions. 
>Neverthe- less, a choice had to be made for the code-sensitive I/O devices and 
>for the programming support, and the solution was to offer both codes, fully 
>supported, as a user option.
>Systems with either option will, of course, easily read or write I/O media 
>with the other code.
>
>
>Aside from that, it wasn't the "P-bit", but the A bit.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EBCDIC/ASCII - FTP

[Phil Smith III]

Thanks. That wasn't obvious to me because I did not get from that Bemer page 
that IBM had erred in not making the 360 ASCII only--just that had the software 
actually supported ASCII, things would have been different. Better? Maybe; it's 
certainly been that case that a ton of resources have been spent on 
ASCII-EBCDIC issues over the years.

Almost as many as have been spent on linends, or null terminated strings (two 
other items on my time-machine list!)

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Marchant
Sent: Wednesday, May 8, 2024 12:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EBCDIC/ASCII - FTP

"This" is the link that Gil provided in the email that I replied to, at the 
bottom of the post. The assertion was that IBM erred in not making the 
System/360 ASCII only.

The availability of multiple EBCDIC code pages seems to me to make Beemer's 
assertion that there is a 1 to 1 correspondence between ASCII and EBCDIC even 
more dubious.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Adoption of ASCII [Was: EBCDIC/ASCII - FTP]

[Mike Schwab]

And beyond the 7 bit ASCII there were many National ASCII code pages
using the 8th bit.

On Wed, May 8, 2024 at 12:07 PM Steve Thompson  wrote:
>
> I think the answer to this question "If IBM had "inflicted" ASCII
> on its customers in 1964, would the System/360 have had the wide
> acceptance that it did?" was the WANG VS series machines. Just
> from my personal experience, many banks were using them, and IBM
> was, to some degree, targeting them with MP2000 & 3000 boxes.
> Again from my experience in programming with the Wang VS systems,
> they appeared to me to be a S/360 with DAT. I think this may have
> been because Dr. Wang waited until the patents expired for the
> S/370 features. I was involved in migrating several of those
> systems into an MVS/JES3 environment (mid-1980s time frame) used
> by a major bank that was buying up small banks that were using
> WANG VS machines. I had to convert their banking software data to
> match Florida Software (for banks) [not to be confused with the
> State of Florida]. Steve Thompson
> On 5/8/2024 11:36 AM, Tom Marchant wrote:
> > I have seen this before, and I am not persuaded. I find it interesting
> > that all of the references provided were written by Mr. Beemer himself,
> > some of them with another author.
> >
> > Perhaps, in hindsight it would have been better if IBM had made the
> > System/360 an ASCII only machine. But at the time, ASCII was new and
> > relatively unknown. As it was, the market had generally rejected ASCII
> > on System/360, so the USASCII bit was removed with the introduction of
> > System/370 in 1970.
> >
> > Both ASCII and EBCDIC are limited. ASCII, even more so because it is a
> > 7 bit code, though there are proprietary 8 bit extensions. No one knew
> > in 1964 that Unicode would later be designed based upon ASCII.
> >
> > The claim that "A 1-to-1 translation between the two [ASCII and EBCDIC]
> > exists" is false.Each includes characters that are not defined in the
> > other. This has always been the case.
> >
> > If IBM had "inflicted" ASCII on its customers in 1964, would the
> > System/360 have had the wide acceptance that it did? We will never know.
> >
> > According to "Architecture of System/360"
> > https://cpb-us-w2.wpmucdn.com/sites.gatech.edu/dist/8/175/files/2015/08/IBM-360.pdf
> >
> > 
> > The reasons against such exclusive adoption was the
> > widespread use of the BCD code derived from and easily
> > translated to the IBM card code. To facilitate use of both
> > codes, the central processing units are designed with a
> > high degree of code independence, with generalized code
> > translation facilities, and with program-selectable BCD or
> > ASCII modes for code-dependent instructions. Neverthe-
> > less, a choice had to be made for the code-sensitive I/O
> > devices and for the programming support, and the solution
> > was to offer both codes, fully supported, as a user option.
> > Systems with either option will, of course, easily read or
> > write I/O media with the other code.
> > 
> >
> > Aside from that, it wasn't the "P-bit", but the A bit.
> >
>
> --
> 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

Adoption of ASCII [Was: EBCDIC/ASCII - FTP]

[Steve Thompson]

I think the answer to this question "If IBM had "inflicted" ASCII 
on its customers in 1964, would the System/360 have had the wide 
acceptance that it did?" was the WANG VS series machines. Just 
from my personal experience, many banks were using them, and IBM 
was, to some degree, targeting them with MP2000 & 3000 boxes. 
Again from my experience in programming with the Wang VS systems, 
they appeared to me to be a S/360 with DAT. I think this may have 
been because Dr. Wang waited until the patents expired for the 
S/370 features. I was involved in migrating several of those 
systems into an MVS/JES3 environment (mid-1980s time frame) used 
by a major bank that was buying up small banks that were using 
WANG VS machines. I had to convert their banking software data to 
match Florida Software (for banks) [not to be confused with the 
State of Florida]. Steve Thompson

On 5/8/2024 11:36 AM, Tom Marchant wrote:

I have seen this before, and I am not persuaded. I find it interesting
that all of the references provided were written by Mr. Beemer himself,
some of them with another author.

Perhaps, in hindsight it would have been better if IBM had made the
System/360 an ASCII only machine. But at the time, ASCII was new and
relatively unknown. As it was, the market had generally rejected ASCII
on System/360, so the USASCII bit was removed with the introduction of
System/370 in 1970.

Both ASCII and EBCDIC are limited. ASCII, even more so because it is a
7 bit code, though there are proprietary 8 bit extensions. No one knew
in 1964 that Unicode would later be designed based upon ASCII.

The claim that "A 1-to-1 translation between the two [ASCII and EBCDIC]
exists" is false.Each includes characters that are not defined in the
other. This has always been the case.

If IBM had "inflicted" ASCII on its customers in 1964, would the
System/360 have had the wide acceptance that it did? We will never know.

According to "Architecture of System/360"
https://cpb-us-w2.wpmucdn.com/sites.gatech.edu/dist/8/175/files/2015/08/IBM-360.pdf


The reasons against such exclusive adoption was the
widespread use of the BCD code derived from and easily
translated to the IBM card code. To facilitate use of both
codes, the central processing units are designed with a
high degree of code independence, with generalized code
translation facilities, and with program-selectable BCD or
ASCII modes for code-dependent instructions. Neverthe-
less, a choice had to be made for the code-sensitive I/O
devices and for the programming support, and the solution
was to offer both codes, fully supported, as a user option.
Systems with either option will, of course, easily read or
write I/O media with the other code.


Aside from that, it wasn't the "P-bit", but the A bit.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EBCDIC/ASCII - FTP

[Tom Marchant]

"This" is the link that Gil provided in the email that I replied to, at the 
bottom of the post. The assertion was that IBM erred in not making the 
System/360 ASCII only.

The availability of multiple EBCDIC code pages seems to me to make Beemer's 
assertion that there is a 1 to 1 correspondence between ASCII and EBCDIC even 
more dubious.

-- 
Tom Marchant

On Wed, 8 May 2024 12:05:26 -0400, Phil Smith III  wrote:

>"I have seen this before"--what is "this"?
>
>I'm curious about your assertion that ASCII/EBCDIC cannot translate cleanly. 
>With the right EBCDIC code page, we do this every day. The basic etoa() and 
>atoe() work fine, have not caused problems--and we care a lot about specific 
>characters, as we support "encrypt in EBCDIC, decrypt in ASCII" and vice versa 
>with Format-Preserving Encryption.
>
>It seems clear that if IBM had inflicted (no scare quotes needed) ASCII as the 
>native encoding for S/360, there would have been more resistance. OTOH it's 
>not clear what realistic choice those customers would have had. There is 
>always the "If I have to do a conversion, I will at least look at 
>alternatives", and with IBM's fate hanging on the success of S/360, maybe that 
>would have been the proverbial straw; we'll never know.
>
>-Original Message-
>From: IBM Mainframe Discussion List  On Behalf Of 
>Tom Marchant
>Sent: Wednesday, May 8, 2024 11:37 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: EBCDIC/ASCII - FTP
>
>I have seen this before, and I am not persuaded. I find it interesting that 
>all of the references provided were written by Mr. Beemer himself, some of 
>them with another author.
>
>Perhaps, in hindsight it would have been better if IBM had made the
>System/360 an ASCII only machine. But at the time, ASCII was new and 
>relatively unknown. As it was, the market had generally rejected ASCII on 
>System/360, so the USASCII bit was removed with the introduction of
>System/370 in 1970.
>
>Both ASCII and EBCDIC are limited. ASCII, even more so because it is a
>7 bit code, though there are proprietary 8 bit extensions. No one knew in 1964 
>that Unicode would later be designed based upon ASCII.
>
>The claim that "A 1-to-1 translation between the two [ASCII and EBCDIC] 
>exists" is false.Each includes characters that are not defined in the other. 
>This has always been the case.
>
>If IBM had "inflicted" ASCII on its customers in 1964, would the
>System/360 have had the wide acceptance that it did? We will never know.
>
>According to "Architecture of System/360" 
>https://cpb-us-w2.wpmucdn.com/sites.gatech.edu/dist/8/175/files/2015/08/IBM-360.pdf
>
>
>The reasons against such exclusive adoption was the widespread use of the BCD 
>code derived from and easily translated to the IBM card code. To facilitate 
>use of both codes, the central processing units are designed with a high 
>degree of code independence, with generalized code translation facilities, and 
>with program-selectable BCD or ASCII modes for code-dependent instructions. 
>Neverthe- less, a choice had to be made for the code-sensitive I/O devices and 
>for the programming support, and the solution was to offer both codes, fully 
>supported, as a user option.
>Systems with either option will, of course, easily read or write I/O media 
>with the other code.
>
>
>Aside from that, it wasn't the "P-bit", but the A bit.
>
>--
>Tom Marchant
>
>On Wed, 1 May 2024 11:31:56 -0500, Paul Gilmartin  wrote:
>
>>Seriously!?  After IBM inflicted the burden of EBCDIC on users:
>><https://web.archive.org/web/20180513204153/http://www.bobbemer.com/P-B
>>IT.HTM> it chooses to torment them with the need to learn different 
>>conventions for various products?  Consistency would be a boon here.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
>lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EBCDIC/ASCII - FTP

[Phil Smith III]

"I have seen this before"--what is "this"?

I'm curious about your assertion that ASCII/EBCDIC cannot translate cleanly. 
With the right EBCDIC code page, we do this every day. The basic etoa() and 
atoe() work fine, have not caused problems--and we care a lot about specific 
characters, as we support "encrypt in EBCDIC, decrypt in ASCII" and vice versa 
with Format-Preserving Encryption.

It seems clear that if IBM had inflicted (no scare quotes needed) ASCII as the 
native encoding for S/360, there would have been more resistance. OTOH it's not 
clear what realistic choice those customers would have had. There is always the 
"If I have to do a conversion, I will at least look at alternatives", and with 
IBM's fate hanging on the success of S/360, maybe that would have been the 
proverbial straw; we'll never know.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Tom 
Marchant
Sent: Wednesday, May 8, 2024 11:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: EBCDIC/ASCII - FTP

I have seen this before, and I am not persuaded. I find it interesting that all 
of the references provided were written by Mr. Beemer himself, some of them 
with another author.

Perhaps, in hindsight it would have been better if IBM had made the
System/360 an ASCII only machine. But at the time, ASCII was new and relatively 
unknown. As it was, the market had generally rejected ASCII on System/360, so 
the USASCII bit was removed with the introduction of
System/370 in 1970.

Both ASCII and EBCDIC are limited. ASCII, even more so because it is a
7 bit code, though there are proprietary 8 bit extensions. No one knew in 1964 
that Unicode would later be designed based upon ASCII.

The claim that "A 1-to-1 translation between the two [ASCII and EBCDIC] exists" 
is false.Each includes characters that are not defined in the other. This has 
always been the case.

If IBM had "inflicted" ASCII on its customers in 1964, would the
System/360 have had the wide acceptance that it did? We will never know.

According to "Architecture of System/360" 
https://cpb-us-w2.wpmucdn.com/sites.gatech.edu/dist/8/175/files/2015/08/IBM-360.pdf


The reasons against such exclusive adoption was the widespread use of the BCD 
code derived from and easily translated to the IBM card code. To facilitate use 
of both codes, the central processing units are designed with a high degree of 
code independence, with generalized code translation facilities, and with 
program-selectable BCD or ASCII modes for code-dependent instructions. 
Neverthe- less, a choice had to be made for the code-sensitive I/O devices and 
for the programming support, and the solution was to offer both codes, fully 
supported, as a user option.
Systems with either option will, of course, easily read or write I/O media with 
the other code.


Aside from that, it wasn't the "P-bit", but the A bit.

--
Tom Marchant

On Wed, 1 May 2024 11:31:56 -0500, Paul Gilmartin  wrote:

>Seriously!?  After IBM inflicted the burden of EBCDIC on users:
><https://web.archive.org/web/20180513204153/http://www.bobbemer.com/P-B
>IT.HTM> it chooses to torment them with the need to learn different 
>conventions for various products?  Consistency would be a boon here.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EBCDIC/ASCII - FTP

[Tom Marchant]

I have seen this before, and I am not persuaded. I find it interesting 
that all of the references provided were written by Mr. Beemer himself, 
some of them with another author.

Perhaps, in hindsight it would have been better if IBM had made the 
System/360 an ASCII only machine. But at the time, ASCII was new and 
relatively unknown. As it was, the market had generally rejected ASCII 
on System/360, so the USASCII bit was removed with the introduction of 
System/370 in 1970.

Both ASCII and EBCDIC are limited. ASCII, even more so because it is a 
7 bit code, though there are proprietary 8 bit extensions. No one knew 
in 1964 that Unicode would later be designed based upon ASCII.

The claim that "A 1-to-1 translation between the two [ASCII and EBCDIC] 
exists" is false.Each includes characters that are not defined in the 
other. This has always been the case.

If IBM had "inflicted" ASCII on its customers in 1964, would the 
System/360 have had the wide acceptance that it did? We will never know.

According to "Architecture of System/360" 
https://cpb-us-w2.wpmucdn.com/sites.gatech.edu/dist/8/175/files/2015/08/IBM-360.pdf


The reasons against such exclusive adoption was the
widespread use of the BCD code derived from and easily
translated to the IBM card code. To facilitate use of both
codes, the central processing units are designed with a
high degree of code independence, with generalized code
translation facilities, and with program-selectable BCD or
ASCII modes for code-dependent instructions. Neverthe-
less, a choice had to be made for the code-sensitive I/O
devices and for the programming support, and the solution
was to offer both codes, fully supported, as a user option.
Systems with either option will, of course, easily read or
write I/O media with the other code.


Aside from that, it wasn't the "P-bit", but the A bit.

-- 
Tom Marchant

On Wed, 1 May 2024 11:31:56 -0500, Paul Gilmartin  wrote:

>Seriously!?  After IBM inflicted the burden of EBCDIC on users:
>
>it chooses to torment them with the need to learn different conventions for
>various products?  Consistency would be a boon here.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EBCDIC/ASCII - FTP

[Massimo Biancucci]

At some customer I use a java zip tool derived from IBM sample that can
convert to a destination (e.g. IBM850, UTF-8 etc.) CCSID on the fly.
Of course the whole byte sequence must be zoned character or you'll
encounter issues reading file after unzipping at the destination.

Best regards.
Max

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
Privo
di virus.www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Il giorno mer 1 mag 2024 alle ore 04:10 BM <
0634aa61051b-dmarc-requ...@listserv.ua.edu> ha scritto:

> Looking for expert's opinions/solutions here.
>
> Trying to FTP large file from zOS2.5 to Windows server using FTP protocol
> but it's taking more time, trying to compress file on zOS (TRSMAIN) then
> ftping, its quick but at destination (Windows) it's not readable after
> Unterse.
>
> On zOS, its EBCDIC file, is there any solution first convert to ASCII then
> Terse send?
>
> Or any tools that can help on windows system to convert data from EBCDIC
> to ASCII after Unterse?
>
> Appreciate your input.
>
>
> Thanks,
> BM
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EBCDIC/ASCII - FTP

[Sri Hari Kolusu]

Gil,

Appendix D in the Application programming guide shows the EBCDIC and ASCII 
collating sequences.

ALTSEQ, CHALT, and LOCALE can be used to select alternate collating sequences 
for character data.

https://www.ibm.com/docs/en/zos/3.1.0?topic=guide-ebcdic-ascii-collating-sequences


Thanks,
Kolusu
DFSORT Development
IBM Corporation



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EBCDIC/ASCII - FTP

[Paul Gilmartin]

On Wed, 1 May 2024 05:38:06 +, Sri Hari Kolusu wrote:
> .
>>>Likewise, what are the CCSIDs in the ASCII and EBCDIC maps in the appendices 
>>>of the DFSORT Ref?
>And what EBCDIC CCSID(s) is/are used by DFSORT regular expressions?
>
>1047-US is the code page that DFSORT uses for Regular expressions.
> .
Does "Table 109. EBCDIC Collating Sequence" in z/OS: z/OS DFSORT
Application Programming Guide correspond to 1047-US?  It would be a
courtesy to users if the table heading identified the CCSID.

But the brackets seem to be incorrect for 1047 and I see no braces at all
(they appear only in rhe ASCII table)  and the table is replete with
revision bars (EBCDIC changed!?) and I see no explanation for those
in the Summary of changes for z/OS 3.1.


>DFSORT is not ISPF and vice-versa. Why do want 2 different products to do the 
>same function?  I am not sure as why you always draw a comparison of 2 
>different products.
> .
Seriously!?  After IBM inflicted the burden of EBCDIC on users:

it chooses to torment them with the need to learn different conventions for
various products?  Consistency would be a boon here.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EBCDIC/ASCII - FTP

[Bernd Oppolzer]

The first question I would like to ask with such tasks - just to make sure:

are there any binary parts in the source EBCDIC files, like packed 
decimal or binary numeric data,
or is it just plain EBCDIC text - with maybe zoned decimal digits (X'f0' 
to x'f9')?


if there are binary parts, you are lost ...

you must first encode the z/OS files so that all the binary parts are 
translated to readable text
BEFORE you even try to transfer them to the ASCII platform. Otherwise, 
you can do only binary FTP
and then you have to do the translation of the text parts later on the 
ASCII platform ... and you will
have the problems with endianness and so on (and there is no easy way to 
work with packed decimal data

on most ASCII platforms).

HTH,
kind regards

Bernd


Am 01.05.2024 um 04:10 schrieb BM:

Looking for expert's opinions/solutions here.

Trying to FTP large file from zOS2.5 to Windows server using FTP protocol but 
it's taking more time, trying to compress file on zOS (TRSMAIN) then ftping, 
its quick but at destination (Windows) it's not readable after Unterse.

On zOS, its EBCDIC file, is there any solution first convert to ASCII then 
Terse send?

Or any tools that can help on windows system to convert data from EBCDIC to 
ASCII after Unterse?

Appreciate your input.


Thanks,
BM

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EBCDIC/ASCII - FTP

[Sri Hari Kolusu]

>> What UNTERSE tool is available on Windows?  Linux?

Gil,

WWunterse from Watson walker.  Announcement here

https://community.ibm.com/community/user/ibmz-and-linuxone/discussion/free-product-to-unterse-smf-and-vb-data-on-distributed-platforms

Direct download link

https://www.ap4zlabs.com/wwunterse


>> What are the CCSIDs used by "the default standard TCP/IP service 
>> EBCDIC-to-ASCII translation table?"

I remember discussing this issue with you before, any way here is the 
translation table used by DFSORT.

https://www.ibm.com/docs/en/zos/3.1.0?topic=statements-outfil-control#oufcst__etoacon

>>Likewise, what are the CCSIDs in the ASCII and EBCDIC maps in the appendices 
>>of the DFSORT Ref?
And what EBCDIC CCSID(s) is/are used by DFSORT regular expressions?

1047-US is the code page that DFSORT uses for Regular expressions.


>> Are they flexible, as in ISPF Edit which selects according to the terminal 
>> CCSID?:
,
supporting several dozen?  (I suspect this an LE facility.) How does the 
programmer indicate to DFSORT which CCSID to use for regular expressions?  Many 
terminal emulators allow a choice, and individual preferences vary.

DFSORT is not ISPF and vice-versa. Why do want 2 different products to do the 
same function?  I am not sure as why you always draw a comparison of 2 
different products.

>>.How does the programmer indicate to DFSORT which CCSID to use for regular 
>>expressions?  Many terminal emulators allow a choice, and individual 
>>preferences vary.

You cannot.   If you want support for plethora of CCSID's then you are better 
off coding a Unicode Character conversion program which would suffice all your 
requirements.

https://www.ibm.com/docs/en/zos/3.1.0?topic=conversion-character

I am positive that you would even find an issue with that service.  I am not 
sure if you have a real requirement, or you just want to evoke a response for a 
hypothetical scenario.

 
Thanks,
Kolusu


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EBCDIC/ASCII - FTP

[Paul Gilmartin]

On Wed, 1 May 2024 03:23:06 +, Sri Hari Kolusu  wrote:

>>> On zOS, its EBCDIC file, is there any solution first convert to ASCII then 
>>> Terse send?
>
Also: .

(Remember to fix the lineends.)

What UNTERSE tool is available on Windows?  Linux?


>You can use DFSORT TRAN=ETOA function which translates characters from EBCDIC 
>to ASCII using the default standard TCP/IP service EBCDIC-to-ASCII translation 
>table. For example, with TRAN=ETOA, the EBCDIC characters aB2 (X'81C2F2') 
>would be replaced by the ASCII characters aB2 (X'614232').
>
What are the CCSIDs used by "the default standard TCP/IP service EBCDIC-to-ASCII
translation table?"

Likewise, what are the CCSIDs in the ASCII and EBCDIC maps in the
appendices of the DFSORT Ref?

And what EBCDIC CCSID(s) is/are used by DFSORT regular expressions?
Are they flexible, as in ISPF Edit which selects according to the terminal 
CCSID?:
,
supporting several dozen?  (I suspect this an LE facility.)
How does the programmer indicate to DFSORT which CCSID to use for regular
expressions?  Many terminal emulators allow a choice, and individual
preferences vary.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EBCDIC/ASCII - FTP

[Sri Hari Kolusu]

>> On zOS, its EBCDIC file, is there any solution first convert to ASCII then 
>> Terse send?

BM,

You can use DFSORT TRAN=ETOA function which translates characters from EBCDIC 
to ASCII using the default standard TCP/IP service EBCDIC-to-ASCII translation 
table. For example, with TRAN=ETOA, the EBCDIC characters aB2 (X'81C2F2') would 
be replaced by the ASCII characters aB2 (X'614232').

//STEP0100 EXEC PGM=SORT
//SYSOUT   DD SYSOUT=*
//SORTIN   DD DISP=SHR,DSN=Your.input.FB.EBCDIC.file
//SORTOUT  DD DSN=your.output.FB.ASCII.file,
//DISP=(NEW,CATLG,DELETE),
//SPACE=(CYL,(X,Y),RLSE)
//SYSINDD *
  OPTION COPY
  OUTREC BUILD=(1,lrecl,TRAN=ETOA)
//*

•   Pass the value of lrecl as numeric.

If your input is a VB file, then use the following control cards

//SYSINDD *
  OPTION COPY
  OUTREC BUILD=(1,4,5,TRAN=ETOA)
//*

You can terse the output file and then FTP it to windows.

Thanks,
Kolusu
DFSORT Development
IBM Corporation


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EBCDIC/ASCII - FTP

[Phil Smith III]

BM wrote, in part:
>On zOS, its EBCDIC file, is there any solution first convert to ASCII then 
>Terse send?

Google is your friend:
"z/os" "convert to ascii"
immediately found lots of discussion, including 
https://bit.listserv.ibm-main.narkive.com/kIFvk8fr/data-conversion-ebcdic-to-ascii
which suggests OCOPY, among other things.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

EBCDIC/ASCII - FTP

[BM]

Looking for expert's opinions/solutions here.

Trying to FTP large file from zOS2.5 to Windows server using FTP protocol but 
it's taking more time, trying to compress file on zOS (TRSMAIN) then ftping, 
its quick but at destination (Windows) it's not readable after Unterse.

On zOS, its EBCDIC file, is there any solution first convert to ASCII then 
Terse send?

Or any tools that can help on windows system to convert data from EBCDIC to 
ASCII after Unterse?

Appreciate your input.


Thanks,
BM

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: FTP translate table defaults

[Radoslaw Skorupka]

Some clarification, but first - THANK YOU GENTLEMEN.

My problem with translation is minor and I know how to circumvent it.
I can use SITE SBD command. The command with codepage numbers or the 
table. Issued directly or embedded in RC file (kind of .profile for FTP 
session).
My question was: How to customize *default* translation table for given 
user. Not globally for server, but for user. The idea was to use several 
users with different translation settings. Instead I can still issue 
SITE SBD, but I want to avoid it.
So, out of curiosity I tried to provide user default translation 
table... with no effect.
Note, changes in server configuration is not an option, because it is 
global, not user-dependent (I wrote it, but I want to repeat).


And this is not end of my questions... :-)

--
Radoslaw Skorupka
Lodz, Poland





W dniu 05.04.2024 o 20:16, Phil Smith III pisze:

Good questions. SITE CHTAG doesn't work. This is an enduring mystery to me.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Friday, April 5, 2024 2:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FTP translate table defaults

On Fri, 5 Apr 2024 13:32:46 -0400, Phil Smith IIIwrote:

...
I don't have a solid answer other than that file tagging seems to matter, so 
chtag is your friend.
.

Does the FTP server have such as a SITE CHTAG command?

Will FTP automatically tag a file to the value in SBDATACONN?

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: FTP translate table defaults

[Phil Smith III]

Good questions. SITE CHTAG doesn't work. This is an enduring mystery to me.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Friday, April 5, 2024 2:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FTP translate table defaults

On Fri, 5 Apr 2024 13:32:46 -0400, Phil Smith IIIwrote:
>...
>I don't have a solid answer other than that file tagging seems to matter, so 
>chtag is your friend.
> .
Does the FTP server have such as a SITE CHTAG command?

Will FTP automatically tag a file to the value in SBDATACONN?

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: FTP translate table defaults

[Paul Gilmartin]

On Fri, 5 Apr 2024 13:32:46 -0400, Phil Smith IIIwrote:
>...
>I don't have a solid answer other than that file tagging seems to matter, so 
>chtag is your friend.
> .
Does the FTP server have such as a SITE CHTAG command?

Will FTP automatically tag a file to the value in SBDATACONN?

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: FTP translate table defaults

[Phil Smith III]

Radoslaw asked about default translate tables for FTP. My earlier thread titled 
"FTP problem", here and MVS-OE, seems related.

I don't have a solid answer other than that file tagging seems to matter, so 
chtag is your friend.

Or I've misunderstood the question, of course.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: FTP translate table defaults

[Michael Oujesky]

See EZY2640I in your FTP log.  Ours:
EZY2640I Using 'TCPIP.FTP.DATA' for local site configuration parameters.
You will want to investigate the SBDATACONN setting.

We encountered translation issues using the default translation table 
(TCPIP.STANDARD.TCPXLBIN) that gave a mu in the translated text for a 
vertical line (used in formatting comments in code).  We ended up 
using CONVXLAT to provide a better table for EBCDIC to ASCII 
translation,  Our JCL:

/SYSTSPRT DD SYSOUT=*
/SYSPRINT DD SYSOUT=*
/SYSINDD DUMMY
/SYSTSIN DD *
onvxlat 'TCPIP.SEZATCPX(EUS)' +
'TCPIP.eus.tcpxlbin'
*
And in the FTP processing statements include:
LOCSITE SBDataconn=TCPIP.eus.tcpxlbin
to override the FTP default table.

Hope that helps.

Michael

At 03:36 PM 4/4/2024, Radoslaw Skorupka wrote:

Content-Transfer-Encoding: 7bit

Scenario:
ftp client (Windows or Linux) is connecting to z/OS based FTP server.
The user has TSO segment and obviously OMVS one. => 
userid.DATASETS.EXIST and /u/userid/home/exists
I can change translation table, I can use RC file to issue some 
commands including SBDATACONN.
However I wanted to use default translation table. I have read 
several manuals and I'm still lost.
I have found several (many!) different "translation table 
hierarchies", varying depending on various factors. But still don't 
know how the hierarchy works. Is it first catch rule or rather last entry wins?
That's important because I want to use different tables for 
different users and cannot change server's settings (which are not 
specified AFAIK).


Any clue?



--

Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

FTP translate table defaults

[Radoslaw Skorupka]

Scenario:
ftp client (Windows or Linux) is connecting to z/OS based FTP server.
The user has TSO segment and obviously OMVS one. => 
userid.DATASETS.EXIST and /u/userid/home/exists
I can change translation table, I can use RC file to issue some commands 
including SBDATACONN.
However I wanted to use default translation table. I have read several 
manuals and I'm still lost.
I have found several (many!) different "translation table hierarchies", 
varying depending on various factors. But still don't know how the 
hierarchy works. Is it first catch rule or rather last entry wins?
That's important because I want to use different tables for different 
users and cannot change server's settings (which are not specified AFAIK).


Any clue?



--

Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: FTP SBDATACONN - how to display?

[Radoslaw Skorupka]

Correction:
SITE STAT (SBD sometimes show the truth.
Sometimes, because it shows last accepted SITE 
SBDATACONN=(ibm-870,IBM1250), as it was entered (note the missing hyphen 
in IBM1250).

However it does show neither translation table nor default value.


--
Radoslaw Skorupka
Lodz, Poland





W dniu 25.03.2024 o 18:52, Paul Gilmartin pisze:

On Mon, 25 Mar 2024 16:39:22 +0100, Radoslaw Skorupka wrote:

what does [QUOTE [SITE]] STAT tell you?

The output is long, but it does not contain translation details.
However it shows "ENcoding is set to SBCS".


Feels like an invitation to an Idea.


Note, SITE STAT (SBD   or SITE STAT (ENCODING are not helpful also.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: FTP SBDATACONN - how to display?

[Paul Gilmartin]

On Mon, 25 Mar 2024 16:39:22 +0100, Radoslaw Skorupka wrote:
>>>
>> what does [QUOTE [SITE]] STAT tell you?
>
>The output is long, but it does not contain translation details.
>However it shows "ENcoding is set to SBCS".
> 
Feels like an invitation to an Idea.

>Note, SITE STAT (SBD   or SITE STAT (ENCODING are not helpful also.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: FTP SBDATACONN - how to display?

[Radoslaw Skorupka]

W dniu 24.03.2024 o 23:17, Paul Gilmartin pisze:

On Sun, 24 Mar 2024 21:46:37 +0100, Radoslaw Skorupka wrote:


How to display current settings of SBDATACONN?
I mean translation details.
The server is running on z/OS, the client is Windows or Linux (text
mode, no GUI clients).


what does [QUOTE [SITE]] STAT tell you?


The output is long, but it does not contain translation details.
However it shows "ENcoding is set to SBCS".

Note, SITE STAT (SBD   or SITE STAT (ENCODING are not helpful also.

--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: FTP SBDATACONN - how to display?

[Sri Hari Kolusu]

>> I mean translation details.

Radoslaw,

Check this 
https://www.ibm.com/support/pages/overview-using-data-translation-zos-ftp

https://www.ibm.com/docs/en/zos/2.5.0?topic=protocol-ftp-configuration-statements-in-ftpdata

Thanks,
Kolusu

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: FTP SBDATACONN - how to display?

[Paul Gilmartin]

On Sun, 24 Mar 2024 21:46:37 +0100, Radoslaw Skorupka wrote:

>How to display current settings of SBDATACONN?
>I mean translation details.
>The server is running on z/OS, the client is Windows or Linux (text
>mode, no GUI clients).
> 
what does [QUOTE [SITE]] STAT tell you?

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

FTP SBDATACONN - how to display?

[Radoslaw Skorupka]

How to display current settings of SBDATACONN?
I mean translation details.
The server is running on z/OS, the client is Windows or Linux (text 
mode, no GUI clients).



BTW: Do exist any presentations regarding ftp multi-platform issues like 
EBCDIC-ASCII or dataset-file conversions?

I do RTFM, but the manual is not clear for me.

--
Radoslaw Skorupka
Lodz, Poland

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: FTP problem

[Phil Smith III]

Colin Paice wrote:
>It may be interaction with _BPXK_AUTOCVT environment variable, and
>possibly the FILETAG

Hmm. _BPXK_AUTOCVT is ON; setting it to OFF means that a text file tagged as 
ISO8859-1 now displays as garbage, which makes sense. IBM-1047 and untagged 
files display OK. (It also breaks OS-generated text in my shell prompt, which 
is interesting-but not literals in that same prompt.) But it doesn't seem to 
affect FTP, which makes sense-how would I set it for an FTP session? Or are you 
suggesting setting it for the FTP server? It's not set there unless it's 
defaulting.

FILETAG appears to apply only to C/C++. If you meant the tag on the file, 
that's what my chtag was tinkering with.

I feel like I'm arguing with you, and I don't mean to-I appreciate the thoughts!


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: FTP problem

[Colin Paice]

It may be interaction with _BPXK_AUTOCVT environment variable, and possibly
the  FILETAG
Colin

On Tue, 19 Mar 2024 at 18:02, Phil Smith III  wrote:

> Cross-posting this to MVS-OE as a fup to earlier note. TL;DR is that
> FTPing a text file back to Windows was getting binary (unreadable) no
> matter what I'd tried.
>
>
>
> Sorta figured this out, mostly:
>
> > echo woof > txt
>
> > chtag -p txt
>
> t ISO8859-1   T=on  txt
>
>
>
> That file transfers fine as *binary*, which  makes sense, since it's
> apparently 8859-1 on disk. I have other files:
>
> > chtag -p logs/build.log
>
> - untaggedT=off logs/build.log
>
> .that have to be transferred as ASCII, so apparently they're "native"
> (EBCDIC, presumably 1047) on disk.
>
>
>
> The remaining mystery is what's making a random file created via echo (or
> various other things) be ISO8859-1 instead of native EBCDIC?!
>
>
>
> From: Phil Smith III 
> Sent: Monday, October 30, 2023 6:13 PM
> To: 'ibm-m...@bama.ua.edu' 
> Subject: RE: FTP problem
>
>
>
> Off-list reply pointed out that I meant "z/OS FTP server", not "Windows".
> Braincheck. I fire up Windows FTP client, do GETs. And yes, I was
> specifying ASCII. That's what was so weird: it sometimes said
> 125-Tagged ASCII file translated with current data connection translation
> table
> .which is what got me tinkering with chtag. But sometimes it didn't say
> 'translated', and the resulting file was STILL borked!
>
> Annotated:
> * FTPed file, it was borked. Let's tinker with chtag.
> > chtag -p gskinterop.txt
> t ISO8859-1   T=on  gskinterop.txt
>
> * Hmm, 8859-1, that's weird. OK, let's untag it
> > chtag -r gskinterop.txt
>
> > chtag -p gskinterop.txt
> - untaggedT=off gskinterop.txt
>
> * FTPed it again, still borked. Even with explicit ASCII.
>
> * Let's tag it explicitly
> > chtag -t -c ibm-1047 gskinterop.txt
>
> > chtag -p gskinterop.txt
> t IBM-1047T=on  gskinterop.txt
>
> * Still borked.
>
> I started to think something was going on on the Windows side, so I
> replaced the file contents with a * before retrying the above. No change:
> the borked version was full-size, just not translated, apparently. Yes,
> when I look at it on z/OS it looks fine.
>
> Yes I could use scp but that's not how I normally do this.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: FTP problem

[Phil Smith III]

Cross-posting this to MVS-OE as a fup to earlier note. TL;DR is that FTPing a 
text file back to Windows was getting binary (unreadable) no matter what I'd 
tried.

 

Sorta figured this out, mostly:

> echo woof > txt

> chtag -p txt

t ISO8859-1   T=on  txt

 

That file transfers fine as *binary*, which  makes sense, since it's apparently 
8859-1 on disk. I have other files:

> chtag -p logs/build.log

- untaggedT=off logs/build.log

.that have to be transferred as ASCII, so apparently they're "native" (EBCDIC, 
presumably 1047) on disk.

 

The remaining mystery is what's making a random file created via echo (or 
various other things) be ISO8859-1 instead of native EBCDIC?!

 

From: Phil Smith III  
Sent: Monday, October 30, 2023 6:13 PM
To: 'ibm-m...@bama.ua.edu' 
Subject: RE: FTP problem

 

Off-list reply pointed out that I meant "z/OS FTP server", not "Windows". 
Braincheck. I fire up Windows FTP client, do GETs. And yes, I was specifying 
ASCII. That's what was so weird: it sometimes said 
125-Tagged ASCII file translated with current data connection translation table
.which is what got me tinkering with chtag. But sometimes it didn't say 
'translated', and the resulting file was STILL borked!

Annotated:
* FTPed file, it was borked. Let's tinker with chtag.
> chtag -p gskinterop.txt
t ISO8859-1   T=on  gskinterop.txt

* Hmm, 8859-1, that's weird. OK, let's untag it
> chtag -r gskinterop.txt

> chtag -p gskinterop.txt
- untaggedT=off gskinterop.txt

* FTPed it again, still borked. Even with explicit ASCII.

* Let's tag it explicitly
> chtag -t -c ibm-1047 gskinterop.txt

> chtag -p gskinterop.txt
t IBM-1047T=on  gskinterop.txt

* Still borked.

I started to think something was going on on the Windows side, so I replaced 
the file contents with a * before retrying the above. No change: the borked 
version was full-size, just not translated, apparently. Yes, when I look at it 
on z/OS it looks fine.

Yes I could use scp but that's not how I normally do this.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: FTP problem

[Phil Smith III]

Wendell Lovewell wrote:
>fwiw, I wrote a bash script to run gsktrace and ftp it to a Windows
>FTP server. (I connect to z/OS using SSH to run it.)

Thanks.if I had a Windows FTP server (which I don't, despite my original post), 
this would be great. I do a LOT of ftp -i TO this system, some FROM it. This is 
the first time FROM has had a problem. (TO sometimes fails due to random 
network timeouts, but that's another story.)


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: FTP problem

[Wendell Lovewell]

fwiw, I wrote a bash script to run gsktrace and ftp it to a Windows FTP server. 
 (I connect to z/OS using SSH to run it.)

>cat gskput
#!/bin/bash
HOST='winpc'
USER='winuserid'
PASSWD='winpwd'

cd /tmp
rm /tmp/gsk.out
gsktrace /tmp/gskmack.trc > /tmp/gsk.out

ftp -n -v $HOST << EOT
ascii
user $USER $PASSWD
prompt
cd /C/Temp/
put /tmp/gsk.out /C/Temp/gsk.out
quit
EOT
rm gskmack.tmp
rm gsk.out

Transferring it as ascii works for me.

(/C/Temp/ is mapped by the FTP server to a folder on the Windows PC.) 

hth,
Wendell

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: FTP problem

[Phil Smith III]

Off-list reply pointed out that I meant "z/OS FTP server", not "Windows". 
Braincheck. I fire up Windows FTP client, do GETs. And yes, I was specifying 
ASCII. That's what was so weird: it sometimes said 
125-Tagged ASCII file translated with current data connection translation table
.which is what got me tinkering with chtag. But sometimes it didn't say 
'translated', and the resulting file was STILL borked!

Annotated:
* FTPed file, it was borked. Let's tinker with chtag.
> chtag -p gskinterop.txt
t ISO8859-1   T=on  gskinterop.txt

* Hmm, 8859-1, that's weird. OK, let's untag it
> chtag -r gskinterop.txt

> chtag -p gskinterop.txt
- untaggedT=off gskinterop.txt

* FTPed it again, still borked. Even with explicit ASCII.

* Let's tag it explicitly
> chtag -t -c ibm-1047 gskinterop.txt

> chtag -p gskinterop.txt
t IBM-1047T=on  gskinterop.txt

* Still borked.

I started to think something was going on on the Windows side, so I replaced 
the file contents with a * before retrying the above. No change: the borked 
version was full-size, just not translated, apparently. Yes, when I look at it 
on z/OS it looks fine.

Yes I could use scp but that's not how I normally do this.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: FTP problem

[Paul Gilmartin]

On Mon, 30 Oct 2023 15:13:53 -0400, Phil Smith III  wrote:
>
>I realize this is confused, but that's because I'm confused; I'm used to FTP 
>and Ascii and Image and MODE B TYPE E and like that, and think I've tried all 
>options. The fact that it worked once is almost worse.
>
>  
I've had MODE B TYPE E work nicely IBM-to-IBM systems, and desktop systems
that reject either.

Partition the problem.  Use SFTP and a conversion utility such as iconv at
the more convenient end.

I hate EBCDIC!  (And I don't like  very much, either.)

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: FTP problem

[Rick Troth]

Been so many years I forget the syntax but you might be able to force 
the other end to behave appropriately. TYPE E and MODE B for binary 
stuff, yes. But look into "QUOTE" and "SITE" commands in the FTP client 
for sending "TYPE I" or "TYPE A" and the like over to the server.


I hope this helps.
But honestly, I really dislike FTP these days. Have for a long time.
Where I have sign-on, I use 'scp' instead. Where I don't, I use 
HTTP/HTTPS. (And you can throw data sets over the wall to/from USS.)


-- R; <><


On 10/30/23 15:13, Phil Smith III wrote:

I was doing a gsktrace and FTPing the resulting text file (after processing the 
trace file) to Windows. I was getting gibberish. Tinkered with chtag, didn't 
get anywhere. Then I deleted the file and did the gsktrace again, FTPed that, 
it was fine. Next iteration (new trace file) I could not get it to work at all.

  


It looks like Windows FTP server is convinced the file is "mixed" (even when I 
chtag -r it) and thus not doing translation.

  


I realize this is confused, but that's because I'm confused; I'm used to FTP 
and Ascii and Image and MODE B TYPE E and like that, and think I've tried all 
options. The fact that it worked once is almost worse.

  


Ideas?


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

FTP problem

[Phil Smith III]

I was doing a gsktrace and FTPing the resulting text file (after processing the 
trace file) to Windows. I was getting gibberish. Tinkered with chtag, didn't 
get anywhere. Then I deleted the file and did the gsktrace again, FTPed that, 
it was fine. Next iteration (new trace file) I could not get it to work at all.

 

It looks like Windows FTP server is convinced the file is "mixed" (even when I 
chtag -r it) and thus not doing translation.

 

I realize this is confused, but that's because I'm confused; I'm used to FTP 
and Ascii and Image and MODE B TYPE E and like that, and think I've tried all 
options. The fact that it worked once is almost worse.

 

Ideas?


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: looking for RSYNC for OMVS [was: Preferred FTP Client for Windows]

[david rintoul]

rsyncport is available on z/open tools site.-
https://github.com/ZOSOpenTools

On Sat, Jul 29, 2023 at 2:01 AM Rick Troth  wrote:

> And for my next question: what about RSYNC?
> I don't see it mentioned on the Co:Z web site. Didn't find it on
> Rocket's web site either.
> I thought I heard a rumor about someone porting it, but I also don't see
> it under the z/OS Open Tools GitHub repository.
>
> RSYNC is the tool of choice for bulk file transfer on Linux, most Unix,
> MacOS, even Windoze (via CYGWIN, maybe WSL1).
> Stealing verbiage from Lionel, it would be impossible to speak too
> highly about RSYNC as a general tool for maintaining file hierarchies.
> The gotcha for z/OS would be ASCII/EBCDIC mixing, similar problem for
> those who use NFS between USS and other systems.
>
> -- R; <><
>
>
> On 7/28/23 11:38, Tom Brennan wrote:
> > Sounds great!  I've never used Co:Z, but I always assumed it was a mod
> > to the open source SSH code, with a new listening STC.  Interesting to
> > see John's note about it using IBM's SSH processing.  I'm not sure I
> > would have thought of that simple idea myself.
> >
> > Conversations in the past went like this:
> > User: Does the mainframe support sftp?
> > Tom: Sure!
> > User: Ok, so I can sftp PROD.PAYROLL to our Linux app.
> > Tom: Sure!  But... um...
> >
> > On 7/28/2023 8:01 AM, Lionel B. Dyck wrote:
> >> It would be impossible to speak to highly about Co:Z - and not just
> >> about their sftp server enhancement but also their other tools. They
> >> have provided what IBM should have.
> >>
> >> Check the license - it's free with some restrictions. And they offer
> >> a full support contract as well (which I would encourage you to
> >> consider if you're going to use it in production if only to support
> >> this great company).
> >>
> >>
> >> Lionel B. Dyck <><
> >> Website: https://www.lbdsoftware.com
> >> Github: https://github.com/lbdyck
> >>
> >> “Worry more about your character than your reputation. Character is
> >> what you are, reputation merely what others think you are.” - - -
> >> John Wooden
> >>
> >> -Original Message-
> >> From: IBM Mainframe Discussion List  On
> >> Behalf Of John S. Giltner, Jr.
> >> Sent: Friday, July 28, 2023 9:58 AM
> >> To: IBM-MAIN@LISTSERV.UA.EDU
> >> Subject: Re: Preferred FTP Client for Windows
> >>
> >> Co:Z SFTP only talks SSH/SFTP.  It sits "on top" of IBM's ported
> >> OpenSSH.  So you need IBM's OpenSSH installed.
> >>
> >> To get/put z/OS files you do need to use some special command such as
> >> to put  a text file with LRECL=80 and fixed block  to z/OS
> >>
> >> ls /+mode=text,lrecl=80,recmf=fb,blksize=0,space=trk.1.1
> >> put //!ZOS.FILE.NAME
> >>
> >> To get a z/OS file that is text:
> >>
> >> ls /+mode=text
> >> get //ZOS.FILE.NAME
> >>
> >> To do binary it would be ls /+mode=binary.
> >>
> >> For OMVS files the get/put are just like any other *nix host. If the
> >> files are in EBCDIC you need the ls /+mode=text.  If they are binary
> >> or in ASCII you use /+mode=binary/
> >>
> >> Co:Z does have a config file where you can set defaults for mode,
> >> lrecl, blksize and everything else so you don't have to specify the
> >> parameters every time if you know what you going to be using most of
> >> the time.
> >>
> >> You can also use Co:Z as a client on z/OS to send/get files from
> >> other SFTP servers.
> >>
> >> On Fri, 28 Jul 2023 10:25:34 -0400, Rick Troth 
> wrote:
> >>
> >>> This is great to hear, John. Thanks.
> >>>
> >>> For people like me, who need excruciating clarity, you're saying that
> >>> the SERVER in the Co:Z product groks traditional datasets as well as
> >>> USS files. Correct? Fantastic!
> >>> That means one can use a variety of clients, specifically several which
> >>> go via SSH. Is that also correct?
> >>>
> >>> You mention SFTP which is FTP-like behavior using SSH under the covers.
> >>> Contrast with FTPS which is traditional FTP but with SSL/TLS added.
> >>> I'm keen on the former because it uses a single channel. Though I much
> >>> prefer a one-shot command in any case, and 'scp' does that (and runs
> >>> via SSH like 'sftp').
> >>>
> >>> Does the Co:Z server spe

How to list ciphers used in FTP

[Don Johnson]

Hi all!
We are making some changes to one of our internal servers this weekend, and my 
boss would like to confirm the list of ciphers available for FTP clients before 
and after the change.

Is there any subcommand I can issue from my EXEC PGM=FTP client that will list 
the ciphers?

How about from the SSH EXEC PGM=BPXBATCH environment?

Since I need to test both FTP and SFTP access to the servers, I welcome any 
guidance for these that you can give me. The end goal is to produce a 
before/after list showing the differences.

Thanks!
Don Johnson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Preferred FTP Client for Windows

[Kirk Wolf]

In Co:Z, linerule=L4  (4 byte length prefixes) and linerule=rdw (IBM compatible 
RDWs) are different things.   There is also a linerule=mfrdw, but you'll have 
to look at the documentation for that.


Kirk Wolf

On Mon, Jul 31, 2023, at 6:29 PM, Paul Gilmartin wrote:
> On Mon, 31 Jul 2023 17:16:20 -0500, Kirk Wolf wrote:
> 
> >Here's the direct URL to the User's Guide:
> >https://coztoolkit.com/docs/sftp/index.html
> >
> >for FILEDATA=Record, here's an example:
> >
> >ls /+mode=binary,linerule=L4
> >
> >(There are a number of different linerule options, including rdw, crlf, nl, 
> >etc.)
> >
> And I suspect RDW is incompatible with FILE DATA=RECORD.  It takes only
> two IBM designers, not communicating, to achieve that.
> 
> I once did a GET to desktop with format RECORD.  Even as promised it returned
> the RDWs as data.  Than I did a PUT to a different MVS data set with the same
> option.  It faithfully treated the RDW images as data.  Now I have two RDWs on
> each record.  There's no way to create an incident for that:  It's behaving
> precisely as documented.
> 
> -- 
> gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Preferred FTP Client for Windows

[Paul Gilmartin]

On Mon, 31 Jul 2023 17:16:20 -0500, Kirk Wolf wrote:

>Here's the direct URL to the User's Guide:
>https://coztoolkit.com/docs/sftp/index.html
>
>for FILEDATA=Record, here's an example:
>
>ls /+mode=binary,linerule=L4
>
>(There are a number of different linerule options, including rdw, crlf, nl, 
>etc.)
>
And I suspect RDW is incompatible with FILE DATA=RECORD.  It takes only
two IBM designers, not communicating, to achieve that.

I once did a GET to desktop with format RECORD.  Even as promised it returned
the RDWs as data.  Than I did a PUT to a different MVS data set with the same
option.  It faithfully treated the RDW images as data.  Now I have two RDWs on
each record.  There's no way to create an incident for that:  It's behaving
precisely as documented.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Preferred FTP Client for Windows

[Kirk Wolf]

Here's the direct URL to the User's Guide:
https://coztoolkit.com/docs/sftp/index.html

for FILEDATA=Record, here's an example:

ls /+mode=binary,linerule=L4

(There are a number of different linerule options, including rdw, crlf, nl, 
etc.)

Also, if you have Co:Z on both sides, you can use the enhanced "dsput" and 
"dsget" commands to simplify dataset transfer with like allocations, sending 
entire PDS(E)s, etc.

Kirk Wolf
Dovetailed Technologies
https://coztoolkit.com

On Fri, Jul 28, 2023, at 10:43 AM, Paul Gilmartin wrote:
> On Fri, 28 Jul 2023 09:58:04 -0500, John S. Giltner, Jr wrote:
> >...
> >ls /+mode=text
> >
> It's a pity that sftp provides no analogue of QUOTE SITE to do such things 
> cleanly.
> 
> Is there "ls /+mode=record" to deal with FILEDATA=RECORD.  One might want to
> "get" a traditional data set, supplying RDWs for the client.
> 
> Is there support for CCSID tagging?
> 
> Is the reference manual available?
> 
> -- 
> gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Preferred FTP Client for Windows

[Ed Jaffe]

On 7/27/2023 11:44 AM, Schmitt, Michael wrote:

I don't remember what the deal was with NFS when I asked about it 3 years ago.


More than likely its dependence on Kerberos...


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Preferred FTP Client for Windows

[Lionel B. Dyck]

Agreed - poor choice of wording.


Lionel B. Dyck <><
Website: https://www.lbdsoftware.com
Github: https://github.com/lbdyck

“Worry more about your character than your reputation. Character is what you
are, reputation merely what others think you are.”   - - - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Phil Smith III
Sent: Friday, July 28, 2023 1:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Preferred FTP Client for Windows

Lionel wrote:
>It would be impossible to speak to highly about Co:Z 



Presumably you meant "too highly". Just clarifying, as it's easy to read
this as a slam against Co:Z!


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Preferred FTP Client for Windows

[Phil Smith III]

Lionel wrote:
>It would be impossible to speak to highly about Co:Z 



Presumably you meant "too highly". Just clarifying, as it's easy to read this 
as a slam against Co:Z!


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

looking for RSYNC for OMVS [was: Preferred FTP Client for Windows]

[Rick Troth]

And for my next question: what about RSYNC?
I don't see it mentioned on the Co:Z web site. Didn't find it on 
Rocket's web site either.
I thought I heard a rumor about someone porting it, but I also don't see 
it under the z/OS Open Tools GitHub repository.


RSYNC is the tool of choice for bulk file transfer on Linux, most Unix, 
MacOS, even Windoze (via CYGWIN, maybe WSL1).
Stealing verbiage from Lionel, it would be impossible to speak too 
highly about RSYNC as a general tool for maintaining file hierarchies.
The gotcha for z/OS would be ASCII/EBCDIC mixing, similar problem for 
those who use NFS between USS and other systems.


-- R; <><


On 7/28/23 11:38, Tom Brennan wrote:
Sounds great!  I've never used Co:Z, but I always assumed it was a mod 
to the open source SSH code, with a new listening STC.  Interesting to 
see John's note about it using IBM's SSH processing.  I'm not sure I 
would have thought of that simple idea myself.


Conversations in the past went like this:
User: Does the mainframe support sftp?
Tom: Sure!
User: Ok, so I can sftp PROD.PAYROLL to our Linux app.
Tom: Sure!  But... um...

On 7/28/2023 8:01 AM, Lionel B. Dyck wrote:
It would be impossible to speak to highly about Co:Z - and not just 
about their sftp server enhancement but also their other tools. They 
have provided what IBM should have.


Check the license - it's free with some restrictions. And they offer 
a full support contract as well (which I would encourage you to 
consider if you're going to use it in production if only to support 
this great company).



Lionel B. Dyck <><
Website: https://www.lbdsoftware.com
Github: https://github.com/lbdyck

“Worry more about your character than your reputation. Character is 
what you are, reputation merely what others think you are.” - - - 
John Wooden


-Original Message-
From: IBM Mainframe Discussion List  On 
Behalf Of John S. Giltner, Jr.

Sent: Friday, July 28, 2023 9:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Preferred FTP Client for Windows

Co:Z SFTP only talks SSH/SFTP.  It sits "on top" of IBM's ported 
OpenSSH.  So you need IBM's OpenSSH installed.


To get/put z/OS files you do need to use some special command such as 
to put  a text file with LRECL=80 and fixed block  to z/OS


ls /+mode=text,lrecl=80,recmf=fb,blksize=0,space=trk.1.1
put //!ZOS.FILE.NAME

To get a z/OS file that is text:

ls /+mode=text
get //ZOS.FILE.NAME

To do binary it would be ls /+mode=binary.

For OMVS files the get/put are just like any other *nix host. If the 
files are in EBCDIC you need the ls /+mode=text.  If they are binary 
or in ASCII you use /+mode=binary/


Co:Z does have a config file where you can set defaults for mode, 
lrecl, blksize and everything else so you don't have to specify the 
parameters every time if you know what you going to be using most of 
the time.


You can also use Co:Z as a client on z/OS to send/get files from 
other SFTP servers.


On Fri, 28 Jul 2023 10:25:34 -0400, Rick Troth  wrote:


This is great to hear, John. Thanks.

For people like me, who need excruciating clarity, you're saying that
the SERVER in the Co:Z product groks traditional datasets as well as
USS files. Correct? Fantastic!
That means one can use a variety of clients, specifically several which
go via SSH. Is that also correct?

You mention SFTP which is FTP-like behavior using SSH under the covers.
Contrast with FTPS which is traditional FTP but with SSL/TLS added.
I'm keen on the former because it uses a single channel. Though I much
prefer a one-shot command in any case, and 'scp' does that (and runs
via SSH like 'sftp').

Does the Co:Z server speak both SSH (for SFTP) and traditional FTP?

-- R; <><


On 7/28/23 07:34, John S. Giltner, Jr. wrote:
I use sftp  with Co:Z SFTP installed on the z/OS side.  It allows 
access to z/OS files as well as OMVS files.  Where as OpenSSH on 
z/OS only allows access to OMVS files.


Under Windows you can use WSL, Putty, Cygwin, or any other CLI sftp 
product.  I use Cygwin most of the time.



On Wed, 26 Jul 2023 16:06:52 -0500, Steve Estle  
wrote:



Hello All,

I work in a secure government environment and moving files up and 
down from the mainframe (especially traditional ZOS datasets) is a 
'' pita with Winscp and everything I read (including IBMMAIN 
archives) is that tool is just plain dumb when it comes to 
datasets with standard ZOS HLQ's.  I'm trying to do a 
non-scientific poll - what is the preferred FTP client to run on 
Windows platform out there everyone is using that you are happy 
with and can easily navigate to either traditional ZOS HLQ dataset 
or Unix System Services files.  Of course freeware is preferred if 
user friendly.


I know there is Filezilla but not sure it is much better than Winscp?

Thanks for everyone's thoughts and input.

Steve Estle
steven.es...@peraton.com


-- For IBM-MAIN subscribe / 

Re: Preferred FTP Client for Windows

[Allan Staller]

Classification: Confidential

YES.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Rick Troth
Sent: Friday, July 28, 2023 9:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Preferred FTP Client for Windows

[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.]

This is great to hear, John. Thanks.

For people like me, who need excruciating clarity, you're saying that the 
SERVER in the Co:Z product groks traditional datasets as well as USS files. 
Correct? Fantastic!
That means one can use a variety of clients, specifically several which go via 
SSH. Is that also correct?

You mention SFTP which is FTP-like behavior using SSH under the covers.
Contrast with FTPS which is traditional FTP but with SSL/TLS added.
I'm keen on the former because it uses a single channel. Though I much prefer a 
one-shot command in any case, and 'scp' does that (and runs via SSH like 
'sftp').

Does the Co:Z server speak both SSH (for SFTP) and traditional FTP?

-- R; <><


On 7/28/23 07:34, John S. Giltner, Jr. wrote:
> I use sftp  with Co:Z SFTP installed on the z/OS side.  It allows access to 
> z/OS files as well as OMVS files.  Where as OpenSSH on z/OS only allows 
> access to OMVS files.
>
> Under Windows you can use WSL, Putty, Cygwin, or any other CLI sftp product.  
> I use Cygwin most of the time.
>
>
> On Wed, 26 Jul 2023 16:06:52 -0500, Steve Estle  wrote:
>
>> Hello All,
>>
>> I work in a secure government environment and moving files up and down from 
>> the mainframe (especially traditional ZOS datasets) is a '' pita with 
>> Winscp and everything I read (including IBMMAIN archives) is that tool is 
>> just plain dumb when it comes to datasets with standard ZOS HLQ's.  I'm 
>> trying to do a non-scientific poll - what is the preferred FTP client to run 
>> on Windows platform out there everyone is using that you are happy with and 
>> can easily navigate to either traditional ZOS HLQ dataset or Unix System 
>> Services files.  Of course freeware is preferred if user friendly.
>>
>> I know there is Filezilla but not sure it is much better than Winscp?
>>
>> Thanks for everyone's thoughts and input.
>>
>> Steve Estle
>> steven.es...@peraton.com
>>
>> -
>> - For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO
>> IBM-MAIN
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
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

Re: Preferred FTP Client for Windows

[Lionel B. Dyck]

Go to https://coztoolkit.com/downloads/coz/index.html and then click on 
Documentation to read all about it. Then click on License/Support to determine 
if your site qualifies (most do unless you are an outsourcer). Then click 
Downloads and enjoy.


Lionel B. Dyck <><
Website: https://www.lbdsoftware.com
Github: https://github.com/lbdyck

“Worry more about your character than your reputation. Character is what you 
are, reputation merely what others think you are.”   - - - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Friday, July 28, 2023 10:44 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Preferred FTP Client for Windows

On Fri, 28 Jul 2023 09:58:04 -0500, John S. Giltner, Jr wrote:
>...
>ls /+mode=text
>
It's a pity that sftp provides no analogue of QUOTE SITE to do such things 
cleanly.

Is there "ls /+mode=record" to deal with FILEDATA=RECORD.  One might want to 
"get" a traditional data set, supplying RDWs for the client.

Is there support for CCSID tagging?

Is the reference manual available?

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Preferred FTP Client for Windows

[Paul Gilmartin]

On Fri, 28 Jul 2023 09:58:04 -0500, John S. Giltner, Jr wrote:
>...
>ls /+mode=text
>
It's a pity that sftp provides no analogue of QUOTE SITE to do such things 
cleanly.

Is there "ls /+mode=record" to deal with FILEDATA=RECORD.  One might want to
"get" a traditional data set, supplying RDWs for the client.

Is there support for CCSID tagging?

Is the reference manual available?

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Preferred FTP Client for Windows

[Tom Brennan]

Sounds great!  I've never used Co:Z, but I always assumed it was a mod 
to the open source SSH code, with a new listening STC.  Interesting to 
see John's note about it using IBM's SSH processing.  I'm not sure I 
would have thought of that simple idea myself.


Conversations in the past went like this:
User: Does the mainframe support sftp?
Tom: Sure!
User: Ok, so I can sftp PROD.PAYROLL to our Linux app.
Tom: Sure!  But... um...

On 7/28/2023 8:01 AM, Lionel B. Dyck wrote:

It would be impossible to speak to highly about Co:Z - and not just about their 
sftp server enhancement but also their other tools. They have provided what IBM 
should have.

Check the license - it's free with some restrictions. And they offer a full 
support contract as well (which I would encourage you to consider if you're 
going to use it in production if only to support this great company).


Lionel B. Dyck <><
Website: https://www.lbdsoftware.com
Github: https://github.com/lbdyck

“Worry more about your character than your reputation. Character is what you 
are, reputation merely what others think you are.”   - - - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
John S. Giltner, Jr.
Sent: Friday, July 28, 2023 9:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Preferred FTP Client for Windows

Co:Z SFTP only talks SSH/SFTP.  It sits "on top" of IBM's ported OpenSSH.  So 
you need IBM's OpenSSH installed.

To get/put z/OS files you do need to use some special command such as to put  a 
text file with LRECL=80 and fixed block  to z/OS

ls /+mode=text,lrecl=80,recmf=fb,blksize=0,space=trk.1.1
put //!ZOS.FILE.NAME

To get a z/OS file that is text:

ls /+mode=text
get //ZOS.FILE.NAME

To do binary it would be ls /+mode=binary.

For OMVS files the get/put are just like any other *nix host.  If the files are 
in EBCDIC you need the ls /+mode=text.  If they are binary or in ASCII you use 
/+mode=binary/

Co:Z does have a config file where you can set defaults for mode, lrecl, 
blksize and everything else so you don't have to specify the parameters every 
time if you know what you going to be using most of the time.

You can also use Co:Z as a client on z/OS to send/get files from other SFTP 
servers.

On Fri, 28 Jul 2023 10:25:34 -0400, Rick Troth  wrote:


This is great to hear, John. Thanks.

For people like me, who need excruciating clarity, you're saying that
the SERVER in the Co:Z product groks traditional datasets as well as
USS files. Correct? Fantastic!
That means one can use a variety of clients, specifically several which
go via SSH. Is that also correct?

You mention SFTP which is FTP-like behavior using SSH under the covers.
Contrast with FTPS which is traditional FTP but with SSL/TLS added.
I'm keen on the former because it uses a single channel. Though I much
prefer a one-shot command in any case, and 'scp' does that (and runs
via SSH like 'sftp').

Does the Co:Z server speak both SSH (for SFTP) and traditional FTP?

-- R; <><


On 7/28/23 07:34, John S. Giltner, Jr. wrote:

I use sftp  with Co:Z SFTP installed on the z/OS side.  It allows access to 
z/OS files as well as OMVS files.  Where as OpenSSH on z/OS only allows access 
to OMVS files.

Under Windows you can use WSL, Putty, Cygwin, or any other CLI sftp product.  I 
use Cygwin most of the time.


On Wed, 26 Jul 2023 16:06:52 -0500, Steve Estle  wrote:


Hello All,

I work in a secure government environment and moving files up and down from the 
mainframe (especially traditional ZOS datasets) is a '' pita with Winscp 
and everything I read (including IBMMAIN archives) is that tool is just plain 
dumb when it comes to datasets with standard ZOS HLQ's.  I'm trying to do a 
non-scientific poll - what is the preferred FTP client to run on Windows 
platform out there everyone is using that you are happy with and can easily 
navigate to either traditional ZOS HLQ dataset or Unix System Services files.  
Of course freeware is preferred if user friendly.

I know there is Filezilla but not sure it is much better than Winscp?

Thanks for everyone's thoughts and input.

Steve Estle
steven.es...@peraton.com


-- For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO
IBM-MAIN

-
- For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO
IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu wit

Re: Preferred FTP Client for Windows

[Lionel B. Dyck]

It would be impossible to speak to highly about Co:Z - and not just about their 
sftp server enhancement but also their other tools. They have provided what IBM 
should have.

Check the license - it's free with some restrictions. And they offer a full 
support contract as well (which I would encourage you to consider if you're 
going to use it in production if only to support this great company).


Lionel B. Dyck <><
Website: https://www.lbdsoftware.com
Github: https://github.com/lbdyck

“Worry more about your character than your reputation. Character is what you 
are, reputation merely what others think you are.”   - - - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
John S. Giltner, Jr.
Sent: Friday, July 28, 2023 9:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Preferred FTP Client for Windows

Co:Z SFTP only talks SSH/SFTP.  It sits "on top" of IBM's ported OpenSSH.  So 
you need IBM's OpenSSH installed. 

To get/put z/OS files you do need to use some special command such as to put  a 
text file with LRECL=80 and fixed block  to z/OS

ls /+mode=text,lrecl=80,recmf=fb,blksize=0,space=trk.1.1
put //!ZOS.FILE.NAME

To get a z/OS file that is text:

ls /+mode=text
get //ZOS.FILE.NAME

To do binary it would be ls /+mode=binary.

For OMVS files the get/put are just like any other *nix host.  If the files are 
in EBCDIC you need the ls /+mode=text.  If they are binary or in ASCII you use 
/+mode=binary/

Co:Z does have a config file where you can set defaults for mode, lrecl, 
blksize and everything else so you don't have to specify the parameters every 
time if you know what you going to be using most of the time.

You can also use Co:Z as a client on z/OS to send/get files from other SFTP 
servers. 

On Fri, 28 Jul 2023 10:25:34 -0400, Rick Troth  wrote:

>This is great to hear, John. Thanks.
>
>For people like me, who need excruciating clarity, you're saying that 
>the SERVER in the Co:Z product groks traditional datasets as well as 
>USS files. Correct? Fantastic!
>That means one can use a variety of clients, specifically several which 
>go via SSH. Is that also correct?
>
>You mention SFTP which is FTP-like behavior using SSH under the covers.
>Contrast with FTPS which is traditional FTP but with SSL/TLS added.
>I'm keen on the former because it uses a single channel. Though I much 
>prefer a one-shot command in any case, and 'scp' does that (and runs 
>via SSH like 'sftp').
>
>Does the Co:Z server speak both SSH (for SFTP) and traditional FTP?
>
>-- R; <><
>
>
>On 7/28/23 07:34, John S. Giltner, Jr. wrote:
>> I use sftp  with Co:Z SFTP installed on the z/OS side.  It allows access to 
>> z/OS files as well as OMVS files.  Where as OpenSSH on z/OS only allows 
>> access to OMVS files.
>>
>> Under Windows you can use WSL, Putty, Cygwin, or any other CLI sftp product. 
>>  I use Cygwin most of the time.
>>
>>
>> On Wed, 26 Jul 2023 16:06:52 -0500, Steve Estle  wrote:
>>
>>> Hello All,
>>>
>>> I work in a secure government environment and moving files up and down from 
>>> the mainframe (especially traditional ZOS datasets) is a '' pita with 
>>> Winscp and everything I read (including IBMMAIN archives) is that tool is 
>>> just plain dumb when it comes to datasets with standard ZOS HLQ's.  I'm 
>>> trying to do a non-scientific poll - what is the preferred FTP client to 
>>> run on Windows platform out there everyone is using that you are happy with 
>>> and can easily navigate to either traditional ZOS HLQ dataset or Unix 
>>> System Services files.  Of course freeware is preferred if user friendly.
>>>
>>> I know there is Filezilla but not sure it is much better than Winscp?
>>>
>>> Thanks for everyone's thoughts and input.
>>>
>>> Steve Estle
>>> steven.es...@peraton.com
>>>
>>> 
>>> -- For IBM-MAIN subscribe / signoff / archive access instructions, 
>>> send email to lists...@listserv.ua.edu with the message: INFO 
>>> IBM-MAIN
>> -
>> - For IBM-MAIN subscribe / signoff / archive access instructions, 
>> send email to lists...@listserv.ua.edu with the message: INFO 
>> IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions, send 
>email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Preferred FTP Client for Windows

[John S. Giltner, Jr.]

Co:Z SFTP only talks SSH/SFTP.  It sits "on top" of IBM's ported OpenSSH.  So 
you need IBM's OpenSSH installed. 

To get/put z/OS files you do need to use some special command such as to put  a 
text file with LRECL=80 and fixed block  to z/OS

ls /+mode=text,lrecl=80,recmf=fb,blksize=0,space=trk.1.1
put //!ZOS.FILE.NAME

To get a z/OS file that is text:

ls /+mode=text
get //ZOS.FILE.NAME

To do binary it would be ls /+mode=binary.

For OMVS files the get/put are just like any other *nix host.  If the files are 
in EBCDIC you need the ls /+mode=text.  If they are binary or in ASCII you use 
/+mode=binary/

Co:Z does have a config file where you can set defaults for mode, lrecl, 
blksize and everything else so you don't have to specify the parameters every 
time if you know what you going to be using most of the time.

You can also use Co:Z as a client on z/OS to send/get files from other SFTP 
servers. 

On Fri, 28 Jul 2023 10:25:34 -0400, Rick Troth  wrote:

>This is great to hear, John. Thanks.
>
>For people like me, who need excruciating clarity, you're saying that
>the SERVER in the Co:Z product groks traditional datasets as well as USS
>files. Correct? Fantastic!
>That means one can use a variety of clients, specifically several which
>go via SSH. Is that also correct?
>
>You mention SFTP which is FTP-like behavior using SSH under the covers.
>Contrast with FTPS which is traditional FTP but with SSL/TLS added.
>I'm keen on the former because it uses a single channel. Though I much
>prefer a one-shot command in any case, and 'scp' does that (and runs via
>SSH like 'sftp').
>
>Does the Co:Z server speak both SSH (for SFTP) and traditional FTP?
>
>-- R; <><
>
>
>On 7/28/23 07:34, John S. Giltner, Jr. wrote:
>> I use sftp  with Co:Z SFTP installed on the z/OS side.  It allows access to 
>> z/OS files as well as OMVS files.  Where as OpenSSH on z/OS only allows 
>> access to OMVS files.
>>
>> Under Windows you can use WSL, Putty, Cygwin, or any other CLI sftp product. 
>>  I use Cygwin most of the time.
>>
>>
>> On Wed, 26 Jul 2023 16:06:52 -0500, Steve Estle  wrote:
>>
>>> Hello All,
>>>
>>> I work in a secure government environment and moving files up and down from 
>>> the mainframe (especially traditional ZOS datasets) is a '' pita with 
>>> Winscp and everything I read (including IBMMAIN archives) is that tool is 
>>> just plain dumb when it comes to datasets with standard ZOS HLQ's.  I'm 
>>> trying to do a non-scientific poll - what is the preferred FTP client to 
>>> run on Windows platform out there everyone is using that you are happy with 
>>> and can easily navigate to either traditional ZOS HLQ dataset or Unix 
>>> System Services files.  Of course freeware is preferred if user friendly.
>>>
>>> I know there is Filezilla but not sure it is much better than Winscp?
>>>
>>> Thanks for everyone's thoughts and input.
>>>
>>> Steve Estle
>>> steven.es...@peraton.com
>>>
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Preferred FTP Client for Windows

[Rick Troth]

This is great to hear, John. Thanks.

For people like me, who need excruciating clarity, you're saying that 
the SERVER in the Co:Z product groks traditional datasets as well as USS 
files. Correct? Fantastic!
That means one can use a variety of clients, specifically several which 
go via SSH. Is that also correct?


You mention SFTP which is FTP-like behavior using SSH under the covers.
Contrast with FTPS which is traditional FTP but with SSL/TLS added.
I'm keen on the former because it uses a single channel. Though I much 
prefer a one-shot command in any case, and 'scp' does that (and runs via 
SSH like 'sftp').


Does the Co:Z server speak both SSH (for SFTP) and traditional FTP?

-- R; <><


On 7/28/23 07:34, John S. Giltner, Jr. wrote:

I use sftp  with Co:Z SFTP installed on the z/OS side.  It allows access to 
z/OS files as well as OMVS files.  Where as OpenSSH on z/OS only allows access 
to OMVS files.

Under Windows you can use WSL, Putty, Cygwin, or any other CLI sftp product.  I 
use Cygwin most of the time.


On Wed, 26 Jul 2023 16:06:52 -0500, Steve Estle  wrote:


Hello All,

I work in a secure government environment and moving files up and down from the 
mainframe (especially traditional ZOS datasets) is a '' pita with Winscp 
and everything I read (including IBMMAIN archives) is that tool is just plain 
dumb when it comes to datasets with standard ZOS HLQ's.  I'm trying to do a 
non-scientific poll - what is the preferred FTP client to run on Windows 
platform out there everyone is using that you are happy with and can easily 
navigate to either traditional ZOS HLQ dataset or Unix System Services files.  
Of course freeware is preferred if user friendly.

I know there is Filezilla but not sure it is much better than Winscp?

Thanks for everyone's thoughts and input.

Steve Estle
steven.es...@peraton.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Preferred FTP Client for Windows

[John S. Giltner, Jr.]

I use sftp  with Co:Z SFTP installed on the z/OS side.  It allows access to 
z/OS files as well as OMVS files.  Where as OpenSSH on z/OS only allows access 
to OMVS files.

Under Windows you can use WSL, Putty, Cygwin, or any other CLI sftp product.  I 
use Cygwin most of the time.


On Wed, 26 Jul 2023 16:06:52 -0500, Steve Estle  wrote:

>Hello All,
>
>I work in a secure government environment and moving files up and down from 
>the mainframe (especially traditional ZOS datasets) is a '' pita with 
>Winscp and everything I read (including IBMMAIN archives) is that tool is just 
>plain dumb when it comes to datasets with standard ZOS HLQ's.  I'm trying to 
>do a non-scientific poll - what is the preferred FTP client to run on Windows 
>platform out there everyone is using that you are happy with and can easily 
>navigate to either traditional ZOS HLQ dataset or Unix System Services files.  
>Of course freeware is preferred if user friendly.
>
>I know there is Filezilla but not sure it is much better than Winscp?
>
>Thanks for everyone's thoughts and input.
>
>Steve Estle
>steven.es...@peraton.com
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Preferred FTP Client for Windows

[Schmitt, Michael]

I meant IBM doesn't have a solution for mod_mvsds using modern authentication. 
Or so I was told.


I don't remember what the deal was with NFS when I asked about it 3 years ago.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Thursday, July 27, 2023 1:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Preferred FTP Client for Windows

On Thu, 27 Jul 2023 17:18:57 +, Schmitt, Michael wrote:

>z/OS MVS team doesn't want to install NFS.
>
Why?

>Here's another problem: We used to be able to view MVS data sets and members 
>using the IBM web server. I think this is mod_mvsds?
>
Read/Write?

>Anyway, this only works with basic authentication. But basic authentication 
>has been removed from the web browsers for security reasons, either by the web 
>browser company or our corporate rules, or both.
>
>What I've heard is that IBM has no solution.
>
Is that true if you include NFS?

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Preferred FTP Client for Windows

[Paul Gilmartin]

On Thu, 27 Jul 2023 17:18:57 +, Schmitt, Michael wrote:

>z/OS MVS team doesn't want to install NFS.
>
Why?

>Here's another problem: We used to be able to view MVS data sets and members 
>using the IBM web server. I think this is mod_mvsds?
> 
Read/Write?

>Anyway, this only works with basic authentication. But basic authentication 
>has been removed from the web browsers for security reasons, either by the web 
>browser company or our corporate rules, or both.
>
>What I've heard is that IBM has no solution.
>
Is that true if you include NFS?

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Preferred FTP Client for Windows

[Schmitt, Michael]

Also not installed.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Kevin Mckenzie
Sent: Thursday, July 27, 2023 1:05 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Preferred FTP Client for Windows

What about z/OSMF?

--
Kevin McKenzie

External Phone: 845-435-8282, Tie-line: 8-295-8282
z/OS Test Services - Test Architect, Provisioning
z/OS Hardware/Software Interlock


From: IBM Mainframe Discussion List  on behalf of 
Schmitt, Michael 
Date: Thursday, July 27, 2023 at 1:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: [EXTERNAL] Re: Preferred FTP Client for Windows
z/OS MVS team doesn't want to install NFS.


Here's another problem: We used to be able to view MVS data sets and members 
using the IBM web server. I think this is mod_mvsds?

Anyway, this only works with basic authentication. But basic authentication has 
been removed from the web browsers for security reasons, either by the web 
browser company or our corporate rules, or both.

What I've heard is that IBM has no solution.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Thursday, July 27, 2023 11:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Preferred FTP Client for Windows

On Thu, 27 Jul 2023 16:27:23 +, Schmitt, Michael wrote:

>...
>And, WinSCP makes incorrect assumptions about what data looks like coming back 
>from listing PDS libraries. For example, you can not use WinSCP to download a 
>member of a PDS that does not have ISPF statistics.
>
How much of that would DSFS solve?  It should satisfy those assumptions.

Or, shift your paradigm; use NFS.  Otherwise, the problem is overspecified.
The requirement should not be "I want an FTP client ...", but "I want to
access traditional MVS data sets from my desktop."

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Preferred FTP Client for Windows

[Kevin Mckenzie]

What about z/OSMF?

--
Kevin McKenzie

External Phone: 845-435-8282, Tie-line: 8-295-8282
z/OS Test Services - Test Architect, Provisioning
z/OS Hardware/Software Interlock


From: IBM Mainframe Discussion List  on behalf of 
Schmitt, Michael 
Date: Thursday, July 27, 2023 at 1:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: [EXTERNAL] Re: Preferred FTP Client for Windows
z/OS MVS team doesn't want to install NFS.


Here's another problem: We used to be able to view MVS data sets and members 
using the IBM web server. I think this is mod_mvsds?

Anyway, this only works with basic authentication. But basic authentication has 
been removed from the web browsers for security reasons, either by the web 
browser company or our corporate rules, or both.

What I've heard is that IBM has no solution.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Thursday, July 27, 2023 11:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Preferred FTP Client for Windows

On Thu, 27 Jul 2023 16:27:23 +, Schmitt, Michael wrote:

>...
>And, WinSCP makes incorrect assumptions about what data looks like coming back 
>from listing PDS libraries. For example, you can not use WinSCP to download a 
>member of a PDS that does not have ISPF statistics.
>
How much of that would DSFS solve?  It should satisfy those assumptions.

Or, shift your paradigm; use NFS.  Otherwise, the problem is overspecified.
The requirement should not be "I want an FTP client ...", but "I want to
access traditional MVS data sets from my desktop."

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Preferred FTP Client for Windows

[Schmitt, Michael]

z/OS MVS team doesn't want to install NFS.


Here's another problem: We used to be able to view MVS data sets and members 
using the IBM web server. I think this is mod_mvsds?

Anyway, this only works with basic authentication. But basic authentication has 
been removed from the web browsers for security reasons, either by the web 
browser company or our corporate rules, or both.

What I've heard is that IBM has no solution.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Thursday, July 27, 2023 11:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Preferred FTP Client for Windows

On Thu, 27 Jul 2023 16:27:23 +, Schmitt, Michael wrote:

>...
>And, WinSCP makes incorrect assumptions about what data looks like coming back 
>from listing PDS libraries. For example, you can not use WinSCP to download a 
>member of a PDS that does not have ISPF statistics.
>
How much of that would DSFS solve?  It should satisfy those assumptions.

Or, shift your paradigm; use NFS.  Otherwise, the problem is overspecified.
The requirement should not be "I want an FTP client ...", but "I want to
access traditional MVS data sets from my desktop."

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Preferred FTP Client for Windows

[Paul Gilmartin]

On Thu, 27 Jul 2023 16:27:23 +, Schmitt, Michael wrote:

>...
>And, WinSCP makes incorrect assumptions about what data looks like coming back 
>from listing PDS libraries. For example, you can not use WinSCP to download a 
>member of a PDS that does not have ISPF statistics.
>
How much of that would DSFS solve?  It should satisfy those assumptions.

Or, shift your paradigm; use NFS.  Otherwise, the problem is overspecified.
The requirement should not be "I want an FTP client ...", but "I want to
access traditional MVS data sets from my desktop."

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Preferred FTP Client for Windows

[Schmitt, Michael]

I tested it extensively and hit too many issues with the MVS side. I worked 
with the developer, who tried to fix them, but ultimately he gave up.

For example, CD to a subfolder and then enter CD 'node'.

And the more you CD the worse it gets, because WinSCP keeps a cache of past 
directories. You can enter a command that is navigating to a different level in 
the MVS data set and it won't work right.

The reason it is having these problems is that WinSCP.com is really a command 
line interface to the WinSCP GUI application. A GUI FTP client needs to be able 
to display the path to your current directory, so it has to do more than just 
send raw commands and echo back the results. It must /interpret/ the results. 
And that requires deep knowledge of how the server presents the file system.

And it gets worse. Realize that on a z/OS FTP server you can work with both the 
MVS and OpenEdition file systems in the same session; you can switch back and 
forth.  CD to /folder, that's the OpenEdition side, and now CD subfolder 
descends within it. But CD to 'node', now you're on the MVS side.  But, WinSCP 
assumed that there's always a / at the root.


And, WinSCP makes incorrect assumptions about what data looks like coming back 
from listing PDS libraries. For example, you can not use WinSCP to download a 
member of a PDS that does not have ISPF statistics.



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of DAL 
POS Raphael
Sent: Thursday, July 27, 2023 11:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Preferred FTP Client for Windows

Hi Michael,

Try winscp.com command interface.
Works like a charm with MVS dataset.

Ciao,

--
Raphael Dal Pos / z/OS Support
GOSP Generali Operations Services Platform
Infrastructure Services/Technologie et Services Locaux France
11-17, Avenue François Mitterrand
93200 Saint Denis / France
Innovatis 01 B5
SNOW : GIS-SEC-RACF_FR
Group mail : GOSP-SEC-RACF_FR
raphael.dal...@generali.com +(33)1-58-38-59-67
  or mobile +(33)6.24.33.20.87
--
"MVS: Guilty, until proven innocent !!" RDP 2009


-Message d'origine-
De : IBM Mainframe Discussion List  De la part de 
Schmitt, Michael
Envoyé : jeudi 27 juillet 2023 17:40
À : IBM-MAIN@LISTSERV.UA.EDU
Objet : Re: Preferred FTP Client for Windows

Thanks for the MOVEit Freely suggestion, but it doesn't actually work in 
passive mode with our z/OS communications server.

MOVEit Freely is sending command PASV. The server returns:

227 Entering Passive Mode (128,212,110,33,238,85)

Which results in a MOVEit error: Invalid response to PASV.


However, FileZilla is issuing the same PASV command, and getting back a similar 
response:

227 Entering Passive Mode (128,212,110,33,238,127)

Which FileZilla accepts.


So I still maintain that there are NO free command line FTP clients for 
Windows* that support passive mode AND work with the MVS file system. PROVE ME 
WRONG, I beg you.


* installing the Linux subsystem is cheating!



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Wednesday, July 26, 2023 6:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Preferred FTP Client for Windows

Au contraire: 
https://urldefense.com/v3/__https://www.ipswitch.com/resources/free-tools/moveit-freely__;!!KhFLcXQ-_A!xg_d1avlXggVlARp9Bp6fZHYudxg-qHirsTEmi2NnIia3bqWujhWtKvqiER7tmD56BEnY7n9fZsC1Q4x7nLvU9iQKDeBXg$

There is no need for any client to have any special cognizance of the file 
system at the server end. I am sure whoever wrote the Windows command line FTP 
had zero knowledge of z/OS data sets, but it works just fine, as @Bob Bridges 
attests.

And yes, I have used the above product extensively with MVS files.

Charles

On Wed, 26 Jul 2023 22:32:41 +, Schmitt, Michael  
wrote:

>FileZilla for GUI. Windows built-in FTP for command line, but...
>
>There are NO (free) command line FTP clients for Windows that support passive 
>mode AND work with the MVS file system. Zilch. Nada. NOT A SINGLE ONE.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Preferred FTP Client for Windows

[Charles Mills]

I don't have the spare time to run tests proving things but there is absolutely 
no doubt in my mind that I have used it successfully in passive mode, running 
against the IBM Dallas datacenter z/OS.

CM

On Thu, 27 Jul 2023 15:39:57 +, Schmitt, Michael  
wrote:

>Thanks for the MOVEit Freely suggestion, but it doesn't actually work in 
>passive mode with our z/OS communications server.
>
>MOVEit Freely is sending command PASV. The server returns:
>
>227 Entering Passive Mode (128,212,110,33,238,85)
>
>Which results in a MOVEit error: Invalid response to PASV.
...
>
>So I still maintain that there are NO free command line FTP clients for 
>Windows* that support passive mode AND work with the MVS file system. PROVE ME 
>WRONG, I beg you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Preferred FTP Client for Windows

[DAL POS Raphael]

Hi Michael, 

Try winscp.com command interface. 
Works like a charm with MVS dataset. 

Ciao, 

-- 
Raphael Dal Pos / z/OS Support
GOSP Generali Operations Services Platform
Infrastructure Services/Technologie et Services Locaux France
11-17, Avenue François Mitterrand
93200 Saint Denis / France
Innovatis 01 B5 
SNOW : GIS-SEC-RACF_FR
Group mail : GOSP-SEC-RACF_FR 
raphael.dal...@generali.com +(33)1-58-38-59-67 
  or mobile +(33)6.24.33.20.87 
-- 
"MVS: Guilty, until proven innocent !!" RDP 2009 


-Message d'origine-
De : IBM Mainframe Discussion List  De la part de 
Schmitt, Michael
Envoyé : jeudi 27 juillet 2023 17:40
À : IBM-MAIN@LISTSERV.UA.EDU
Objet : Re: Preferred FTP Client for Windows

Thanks for the MOVEit Freely suggestion, but it doesn't actually work in 
passive mode with our z/OS communications server.

MOVEit Freely is sending command PASV. The server returns:

227 Entering Passive Mode (128,212,110,33,238,85)

Which results in a MOVEit error: Invalid response to PASV.


However, FileZilla is issuing the same PASV command, and getting back a similar 
response:

227 Entering Passive Mode (128,212,110,33,238,127)

Which FileZilla accepts.


So I still maintain that there are NO free command line FTP clients for 
Windows* that support passive mode AND work with the MVS file system. PROVE ME 
WRONG, I beg you.


* installing the Linux subsystem is cheating!



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Wednesday, July 26, 2023 6:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Preferred FTP Client for Windows

Au contraire: 
https://urldefense.com/v3/__https://www.ipswitch.com/resources/free-tools/moveit-freely__;!!KhFLcXQ-_A!xg_d1avlXggVlARp9Bp6fZHYudxg-qHirsTEmi2NnIia3bqWujhWtKvqiER7tmD56BEnY7n9fZsC1Q4x7nLvU9iQKDeBXg$
 

There is no need for any client to have any special cognizance of the file 
system at the server end. I am sure whoever wrote the Windows command line FTP 
had zero knowledge of z/OS data sets, but it works just fine, as @Bob Bridges 
attests.

And yes, I have used the above product extensively with MVS files.

Charles

On Wed, 26 Jul 2023 22:32:41 +, Schmitt, Michael  
wrote:

>FileZilla for GUI. Windows built-in FTP for command line, but...
>
>There are NO (free) command line FTP clients for Windows that support passive 
>mode AND work with the MVS file system. Zilch. Nada. NOT A SINGLE ONE.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Preferred FTP Client for Windows

[Schmitt, Michael]

Thanks for the MOVEit Freely suggestion, but it doesn't actually work in 
passive mode with our z/OS communications server.

MOVEit Freely is sending command PASV. The server returns:

227 Entering Passive Mode (128,212,110,33,238,85)

Which results in a MOVEit error: Invalid response to PASV.


However, FileZilla is issuing the same PASV command, and getting back a similar 
response:

227 Entering Passive Mode (128,212,110,33,238,127)

Which FileZilla accepts.


So I still maintain that there are NO free command line FTP clients for 
Windows* that support passive mode AND work with the MVS file system. PROVE ME 
WRONG, I beg you.


* installing the Linux subsystem is cheating!



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: Wednesday, July 26, 2023 6:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Preferred FTP Client for Windows

Au contraire: https://www.ipswitch.com/resources/free-tools/moveit-freely

There is no need for any client to have any special cognizance of the file 
system at the server end. I am sure whoever wrote the Windows command line FTP 
had zero knowledge of z/OS data sets, but it works just fine, as @Bob Bridges 
attests.

And yes, I have used the above product extensively with MVS files.

Charles

On Wed, 26 Jul 2023 22:32:41 +, Schmitt, Michael  
wrote:

>FileZilla for GUI. Windows built-in FTP for command line, but...
>
>There are NO (free) command line FTP clients for Windows that support passive 
>mode AND work with the MVS file system. Zilch. Nada. NOT A SINGLE ONE.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Preferred FTP Client for Windows

[Allan Staller]

Classification: Confidential

WS/SFTP?

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Estle
Sent: Wednesday, July 26, 2023 4:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Preferred FTP Client for Windows

[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.]

Hello All,

I work in a secure government environment and moving files up and down from the 
mainframe (especially traditional ZOS datasets) is a '' pita with Winscp 
and everything I read (including IBMMAIN archives) is that tool is just plain 
dumb when it comes to datasets with standard ZOS HLQ's.  I'm trying to do a 
non-scientific poll - what is the preferred FTP client to run on Windows 
platform out there everyone is using that you are happy with and can easily 
navigate to either traditional ZOS HLQ dataset or Unix System Services files.  
Of course freeware is preferred if user friendly.

I know there is Filezilla but not sure it is much better than Winscp?

Thanks for everyone's thoughts and input.

Steve Estle
steven.es...@peraton.com

--
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

Re: Preferred FTP Client for Windows

[Timothy Sipples]

There are lots of good suggestions. Here's another: If you happen to have IBM 
Personal Communications ("PComm") or Host On-Demand ("HOD") then you already 
have a FTP/FTPS* client. There's a good client built into those products. It 
should understand passive mode and MVS data set vernacular.

* Please use (properly configured) FTPS — FTP with TLS — if you use FTP.

—
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM zSystems/LinuxONE, Asia-Pacific
sipp...@sg.ibm.com


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Preferred FTP Client for Windows

[Paul Gilmartin]

On Wed, 26 Jul 2023 18:50:02 -0500, Charles Mills wrote:

>Au contraire: https://www.ipswitch.com/resources/free-tools/moveit-freely 
>
>There is no need for any client to have any special cognizance of the file 
>system at the server end. I am sure whoever wrote the Windows command line FTP 
>had zero knowledge of z/OS data sets, but it works just fine, as @Bob Bridges 
>attests.
>
Indeed.  The problems arise when clients make unwarranted assumptions
about the format about the format of the reply to LIST/NLST and behave
accordingly.  The conservative and safe behavior is to display the reply on
the client console and let the presumably informed user act properly.

RFC 959 does not, in fact can not, dictate the format of the reply to LIST.

I believe that some mainframe servers have an option (SITE command)
to set the format of LIST to simulated desktop format to support
presumptuous clients.

an idiosyncrasy I noticed with the MVS FTP client is the sequence:
lcd whatever
! pwd
displays, not the target of the "lcd" but the directory from which FTP
was entered.  Apparently the client never bothers to do a "chdir()"
as  I expect from other systems.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Preferred FTP Client for Windows

[Andrew Rowley]

On 27/07/2023 8:32 am, Schmitt, Michael wrote:

FileZilla for GUI. Windows built-in FTP for command line, but...

There are NO (free) command line FTP clients for Windows that support passive 
mode AND work with the MVS file system. Zilch. Nada. NOT A SINGLE ONE.


For command line FTP on Windows, the Windows Subsystem for Linux (WSL) 
provides Linux versions of the FTP client. Much better than the original 
Windows version.


I also use IBM Explorer for z/OS for transferring things to OMVS. I'm 
not sure how easy it is to set it up as a file transfer solution to MVS 
datasets. It requires a component set up on z/OS, but the advantage is 
it uses https connections.


https://www.ibm.com/docs/en/explorer-for-zos


--
Andrew Rowley
Black Hill Software

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Preferred FTP Client for Windows

[Charles Mills]

Au contraire: https://www.ipswitch.com/resources/free-tools/moveit-freely 

There is no need for any client to have any special cognizance of the file 
system at the server end. I am sure whoever wrote the Windows command line FTP 
had zero knowledge of z/OS data sets, but it works just fine, as @Bob Bridges 
attests.

And yes, I have used the above product extensively with MVS files.

Charles

On Wed, 26 Jul 2023 22:32:41 +, Schmitt, Michael  
wrote:

>FileZilla for GUI. Windows built-in FTP for command line, but...
>
>There are NO (free) command line FTP clients for Windows that support passive 
>mode AND work with the MVS file system. Zilch. Nada. NOT A SINGLE ONE.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EXTERNAL EMAIL: Re: Preferred FTP Client for Windows

[Jerry Whitteridge]

Also remember that in most cases (That I know of) you will need to use secure 
FTP and there are also even fewer clients that support FTPS as opposed to SFTP.

Jerry Whitteridge
jerry.whitteri...@albertsons.com
Sr. Manager Managed Services
Albertsons Companies

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Schmitt, Michael
Sent: Wednesday, July 26, 2023 3:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL EMAIL: Re: Preferred FTP Client for Windows

FileZilla for GUI. Windows built-in FTP for command line, but...

There are NO (free) command line FTP clients for Windows that support passive 
mode AND work with the MVS file system. Zilch. Nada. NOT A SINGLE ONE.


Reason is the Windows FTP client doesn't support passive mode. And all the 
third party clients try to be too smart; instead of just passing the entered 
command as is to the server, they try to track your current directory state -- 
and get hopelessly confused by the MVS "directory" syntax.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Estle
Sent: Wednesday, July 26, 2023 4:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Preferred FTP Client for Windows

Hello All,

I work in a secure government environment and moving files up and down from the 
mainframe (especially traditional ZOS datasets) is a '' pita with Winscp 
and everything I read (including IBMMAIN archives) is that tool is just plain 
dumb when it comes to datasets with standard ZOS HLQ's.  I'm trying to do a 
non-scientific poll - what is the preferred FTP client to run on Windows 
platform out there everyone is using that you are happy with and can easily 
navigate to either traditional ZOS HLQ dataset or Unix System Services files.  
Of course freeware is preferred if user friendly.

I know there is Filezilla but not sure it is much better than Winscp?

Thanks for everyone's thoughts and input.

Steve Estle
steven.es...@peraton.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

 Warning: All e-mail sent to this address will be received by the corporate 
e-mail system, and is subject to archival and review by someone other than the 
recipient. This e-mail may contain proprietary information and is intended only 
for the use of the intended recipient(s). If the reader of this message is not 
the intended recipient(s), you are notified that you have received this message 
in error and that any review, dissemination, distribution or copying of this 
message is strictly prohibited. If you have received this message in error, 
please notify the sender immediately.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Preferred FTP Client for Windows

[Schmitt, Michael]

FileZilla for GUI. Windows built-in FTP for command line, but...

There are NO (free) command line FTP clients for Windows that support passive 
mode AND work with the MVS file system. Zilch. Nada. NOT A SINGLE ONE.


Reason is the Windows FTP client doesn't support passive mode. And all the 
third party clients try to be too smart; instead of just passing the entered 
command as is to the server, they try to track your current directory state -- 
and get hopelessly confused by the MVS "directory" syntax.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Estle
Sent: Wednesday, July 26, 2023 4:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Preferred FTP Client for Windows

Hello All,

I work in a secure government environment and moving files up and down from the 
mainframe (especially traditional ZOS datasets) is a '' pita with Winscp 
and everything I read (including IBMMAIN archives) is that tool is just plain 
dumb when it comes to datasets with standard ZOS HLQ's.  I'm trying to do a 
non-scientific poll - what is the preferred FTP client to run on Windows 
platform out there everyone is using that you are happy with and can easily 
navigate to either traditional ZOS HLQ dataset or Unix System Services files.  
Of course freeware is preferred if user friendly.

I know there is Filezilla but not sure it is much better than Winscp?

Thanks for everyone's thoughts and input.

Steve Estle
steven.es...@peraton.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Preferred FTP Client for Windows

[Bob Bridges]

No one's going to like this answer, but for mainframe file transfers I do just 
fine with plain Windows-included FTP.  Granted I use it mostly for transferring 
code - data only occasionally and that over VPN.

For ordinary purposes I use MyFTP.txt to hold the commands; it's easy to modify 
and to store temporarily unneeded GETs and PUTs below the QUIT command, like 
this:

  put talias.rexmvs CLIST(ALIAS)
  get GEN.JCL(TALIAS) "..\otherfolder\TALIAS.txt"
  quit
  
  get spufi.out Auths DBAG.txt

If I need to handle a lot of files, I can always generate a long set of GET or 
PUT commands programmatically.

I execute using a .bat file that assumes the target IP and my user ID, asks for 
my password, creates a full -s command file, then deletes it all after the 
session so my password doesn't stay out there:

@echo off
set myaid=
set mycmd=MyFTP.txt
set mytmp=MyFTP1.txt
echo open nnn.nn.nnn.nn>%mytmp%
echo %myaid%>>%mytmp%

set /p MyPsw=Enter password for %myaid%:
echo %mypsw%>>%mytmp%
set mypsw=

type %mycmd%>>%mytmp%
echo quit>>%mytmp%
ftp -s:%mytmp%
del %mytmp%
set myaid=
set mycmd=
set mytmp=
pause

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Never do today what you can do tomorrow. Something may occur to make you 
regret your premature action.  -Aaron Burr */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Estle
Sent: Wednesday, July 26, 2023 17:07

I work in a secure government environment and moving files up and down from the 
mainframe (especially traditional ZOS datasets) is a '' pita with Winscp 
and everything I read (including IBMMAIN archives) is that tool is just plain 
dumb when it comes to datasets with standard ZOS HLQ's.  I'm trying to do a 
non-scientific poll - what is the preferred FTP client to run on Windows 
platform out there everyone is using that you are happy with and can easily 
navigate to either traditional ZOS HLQ dataset or Unix System Services files.  
Of course freeware is preferred if user friendly.

I know there is Filezilla but not sure it is much better than Winscp?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EXTERNAL EMAIL: Preferred FTP Client for Windows

[Steve Beaver]

I like FileZilla. The downside is the passwords that need to be changed 

Sent from my iPhone

No one said I could type with one thumb 

> On Jul 26, 2023, at 17:02, Jerry Whitteridge 
>  wrote:
> 
> I've found that Filezilla is one of the few that understands MVS as well as 
> Unix formats
> 
> Jerry Whitteridge
> jerry.whitteri...@albertsons.com
> Sr. Manager Managed Services
> Albertsons Companies
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Steve Estle
> Sent: Wednesday, July 26, 2023 2:07 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: EXTERNAL EMAIL: Preferred FTP Client for Windows
> 
> Hello All,
> 
> I work in a secure government environment and moving files up and down from 
> the mainframe (especially traditional ZOS datasets) is a '' pita with 
> Winscp and everything I read (including IBMMAIN archives) is that tool is 
> just plain dumb when it comes to datasets with standard ZOS HLQ's.  I'm 
> trying to do a non-scientific poll - what is the preferred FTP client to run 
> on Windows platform out there everyone is using that you are happy with and 
> can easily navigate to either traditional ZOS HLQ dataset or Unix System 
> Services files.  Of course freeware is preferred if user friendly.
> 
> I know there is Filezilla but not sure it is much better than Winscp?
> 
> Thanks for everyone's thoughts and input.
> 
> Steve Estle
> steven.es...@peraton.com
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> Warning: All e-mail sent to this address will be received by the corporate 
> e-mail system, and is subject to archival and review by someone other than 
> the recipient. This e-mail may contain proprietary information and is 
> intended only for the use of the intended recipient(s). If the reader of this 
> message is not the intended recipient(s), you are notified that you have 
> received this message in error and that any review, dissemination, 
> distribution or copying of this message is strictly prohibited. If you have 
> received this message in error, please notify the sender immediately.
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EXTERNAL EMAIL: Preferred FTP Client for Windows

[Jerry Whitteridge]

I've found that Filezilla is one of the few that understands MVS as well as 
Unix formats

Jerry Whitteridge
jerry.whitteri...@albertsons.com
Sr. Manager Managed Services
Albertsons Companies

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Estle
Sent: Wednesday, July 26, 2023 2:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL EMAIL: Preferred FTP Client for Windows

Hello All,

I work in a secure government environment and moving files up and down from the 
mainframe (especially traditional ZOS datasets) is a '' pita with Winscp 
and everything I read (including IBMMAIN archives) is that tool is just plain 
dumb when it comes to datasets with standard ZOS HLQ's.  I'm trying to do a 
non-scientific poll - what is the preferred FTP client to run on Windows 
platform out there everyone is using that you are happy with and can easily 
navigate to either traditional ZOS HLQ dataset or Unix System Services files.  
Of course freeware is preferred if user friendly.

I know there is Filezilla but not sure it is much better than Winscp?

Thanks for everyone's thoughts and input.

Steve Estle
steven.es...@peraton.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

 Warning: All e-mail sent to this address will be received by the corporate 
e-mail system, and is subject to archival and review by someone other than the 
recipient. This e-mail may contain proprietary information and is intended only 
for the use of the intended recipient(s). If the reader of this message is not 
the intended recipient(s), you are notified that you have received this message 
in error and that any review, dissemination, distribution or copying of this 
message is strictly prohibited. If you have received this message in error, 
please notify the sender immediately.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Preferred FTP Client for Windows

[Paul Gilmartin]

On Wed, 26 Jul 2023 16:06:52 -0500, Steve Estle  wrote:
>
>I work in a secure government environment and moving files up and down from 
>the mainframe (especially traditional ZOS datasets) is a '' pita with 
>Winscp and everything I read (including IBMMAIN archives) is that tool is just 
>plain dumb when it comes to datasets with standard ZOS HLQ's. 
>
What latitude does your secure government environment allow you to
install either free or commercial software:
o On your desktop?
o On z/OS?

Would DSFS circumvent the dumbness concerning traditional ZOS data sets?

I've liked PuTTY and see they have a new collaborator: .

And Rocket products may close the old/new gap:
.

And I've found Cygwin useful: .

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Preferred FTP Client for Windows

[Steve Estle]

Hello All,

I work in a secure government environment and moving files up and down from the 
mainframe (especially traditional ZOS datasets) is a '' pita with Winscp 
and everything I read (including IBMMAIN archives) is that tool is just plain 
dumb when it comes to datasets with standard ZOS HLQ's.  I'm trying to do a 
non-scientific poll - what is the preferred FTP client to run on Windows 
platform out there everyone is using that you are happy with and can easily 
navigate to either traditional ZOS HLQ dataset or Unix System Services files.  
Of course freeware is preferred if user friendly.

I know there is Filezilla but not sure it is much better than Winscp?

Thanks for everyone's thoughts and input.

Steve Estle
steven.es...@peraton.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: FTP client question

[John S. Giltner, Jr.]

In this context it does mean a connection does mean TCP connection.  So once 
the connection is made the source/destination address will stay the same.

One thing I did forget to mention is that the IP address the FTP jobs use can't 
be associated with a specific OSA, so they need to use a VIPA/DVIPA address.

Thinking about this a little more, you may need to do per packet.  With FTP 
there are 2 TCP connections, one for command/control and one for the actual 
data transfers.

If the FTP server you are sending to supports passive data transfers, then 
per-connection will work, but again depending on timing all 3 jobs could still 
go out over a single OSA. 

On Fri, 26 May 2023 16:00:41 -0500, Joel C. Ewing  wrote:

>I suspect "connection" in this context means the opening of a TCP/IP
>socket, which establishes the path between ports on two nodes, and that
>all subsequent packets follow that established path.  That would 
>suggest that transmission of a single file by one FTP instance would
>still be constrained to the bandwidth of a single interface.  My
>understanding of load balancing is that it distributes aggregate load
>over multiple interfaces by spreading multiple transactions over
>multiple paths rather than spreading multiple packets for the same
>transaction over multiple paths--so alternate routes for packets of a
>single FTP transaction wouldn't be an issue.
>
>If your object is to make two 1 Gbps interfaces behave as one 2-Gbps
>interface for a single transaction, I believe that would be closer to
>what is called Ethernet bonding of interfaces.  I know Linux can support
>this if you also have an Ethernet switch that can support bonding (and
>that can support aggregate rates of 2Gbps).  I don't know if that is
>supported on z/OS.  My understanding is that this can allow packets
>associated with the same TCP/IP socket to follow different physical
>paths, but the unit of transmission is still a packet.  FTP transmitting
>a large file supports multiple packets in flight before having to
>receive a response back so it should be able to effectively utilize the
>aggregate bandwidth by spreading those packets over multiple
>interfaces.  If FTP is in an interaction where a single packet is sent
>and a response packet must be received before proceeding, you would
>still be constrained by the bandwidth of a single interface because each
>individual packet still travels over one physical interface.
>
>     JC Ewing
>
>On 5/26/23 10:33, Steve Thompson wrote:
>> I have a question about the alternating of packets.
>>
>> If one is using an MFT product with encryption and hand-shakes, will
>> the alternating packets between routes not cause the "connection" and
>> data xfer(s) to fail?
>>
>> I'm asking because I know just enough about Network traffic to be
>> truly dangerous -- which means I know how to specify an IP address and
>> port#, and not much more.
>>
>> Steve Thompson
>>
>> On 5/26/2023 11:25 AM, John S. Giltner, Jr. wrote:
>>> z/OS can do load balancing if you have mutiple equal cost routes
>>> defined, one route for each OSA and I think they could be the same
>>> route, something like:
>>>
>>>  BeginRoutes
>>>
>>>  route default =  OSA_INTERFACE1
>>>  route default =  OSA_INTERFACE2
>>>
>>>   ENDRoutes
>>>
>>> You could use either default, or code routes for specific
>>> hosts/subnets.  Using default will load balance all outbound traffic,
>>> coding more specific routes will just load blance the traffic for
>>> hosts matching those routes.
>>>
>>> You then add add one of the following statements to your IPCONFIG 
>>> statement.
>>>
>>>    MULTIPATH PERCONNECTION
>>>
>>>    MULTIPATH PERPACKET
>>>
>>> First one will have z/OS alternate which route it takes per TCP
>>> connection.  Connection request #1 get path/route #1, request #2 gets
>>> path/route #2.  Depending on timing all 3 jobs could still get sent
>>> out the same OSA, but you will be using both OSA's so it won't impact
>>> all traffic.
>>>
>>> Second one does the same thing, but per packet.  More overhead but
>>> both OSA's will be used "equally".
>>>
>>> No matter what you do, depending on your network setup either one of
>>> these or, as Keith suggested, defining a ROUTE via a specific
>>> Interface you could overload your network. If your whole
>>> infrastructure is 1 Gbps Ethernet, your z/OS system can now push ~2
>>> Gbps through the network.
>>>
>>>
&g

Re: FTP client question

[Joel C. Ewing]

I suspect "connection" in this context means the opening of a TCP/IP 
socket, which establishes the path between ports on two nodes, and that 
all subsequent packets follow that established path.  That would  
suggest that transmission of a single file by one FTP instance would 
still be constrained to the bandwidth of a single interface.  My 
understanding of load balancing is that it distributes aggregate load 
over multiple interfaces by spreading multiple transactions over 
multiple paths rather than spreading multiple packets for the same 
transaction over multiple paths--so alternate routes for packets of a 
single FTP transaction wouldn't be an issue.


If your object is to make two 1 Gbps interfaces behave as one 2-Gbps 
interface for a single transaction, I believe that would be closer to 
what is called Ethernet bonding of interfaces.  I know Linux can support 
this if you also have an Ethernet switch that can support bonding (and 
that can support aggregate rates of 2Gbps).  I don't know if that is 
supported on z/OS.  My understanding is that this can allow packets 
associated with the same TCP/IP socket to follow different physical 
paths, but the unit of transmission is still a packet.  FTP transmitting 
a large file supports multiple packets in flight before having to 
receive a response back so it should be able to effectively utilize the 
aggregate bandwidth by spreading those packets over multiple 
interfaces.  If FTP is in an interaction where a single packet is sent 
and a response packet must be received before proceeding, you would 
still be constrained by the bandwidth of a single interface because each 
individual packet still travels over one physical interface.


    JC Ewing

On 5/26/23 10:33, Steve Thompson wrote:

I have a question about the alternating of packets.

If one is using an MFT product with encryption and hand-shakes, will 
the alternating packets between routes not cause the "connection" and 
data xfer(s) to fail?


I'm asking because I know just enough about Network traffic to be 
truly dangerous -- which means I know how to specify an IP address and 
port#, and not much more.


Steve Thompson

On 5/26/2023 11:25 AM, John S. Giltner, Jr. wrote:
z/OS can do load balancing if you have mutiple equal cost routes 
defined, one route for each OSA and I think they could be the same 
route, something like:


 BeginRoutes

 route default =  OSA_INTERFACE1
 route default =  OSA_INTERFACE2

  ENDRoutes

You could use either default, or code routes for specific 
hosts/subnets.  Using default will load balance all outbound traffic, 
coding more specific routes will just load blance the traffic for 
hosts matching those routes.


You then add add one of the following statements to your IPCONFIG  
statement.


   MULTIPATH PERCONNECTION

   MULTIPATH PERPACKET

First one will have z/OS alternate which route it takes per TCP 
connection.  Connection request #1 get path/route #1, request #2 gets 
path/route #2.  Depending on timing all 3 jobs could still get sent 
out the same OSA, but you will be using both OSA's so it won't impact 
all traffic.


Second one does the same thing, but per packet.  More overhead but 
both OSA's will be used "equally".


No matter what you do, depending on your network setup either one of 
these or, as Keith suggested, defining a ROUTE via a specific 
Interface you could overload your network. If your whole 
infrastructure is 1 Gbps Ethernet, your z/OS system can now push ~2 
Gbps through the network.



On Thu, 25 May 2023 19:37:10 +0100, Keith Gooding  
wrote:



Hi Rex

Networking is not my speciality but you should be able to add a HOST 
route - see the BEGINROUTES statement in IP Config Reference. 
Something like this:


ROUTE windows server IP address.  HOST   =   OSA_INTERFACE2

where OSA_INTERFACE2 is the interface which you want to use.

This example assumes that the server is on the same subnet as the 
adapter - change - to the router IP address if not.


No guarantees.

Keith Gooding

Sent from my iPad

On 25 May 2023, at 16:41, Pommier, Rex  
wrote:


Hi all,

I have a question about routing FTP traffic.  First a bit about the 
environment.  Z14-zr1 with (2) 1-GbE OSA adapters shared across 3 
LPARs.  The 2 adapters are not in a VIPA configuration.  Right now 
on this LPAR, only 1 of the adapters is defined to TCP/IP.  I can 
easily get the second OSA configured into TCP/IP on the LPAR so 
that's not an issue.


The situation/question.  I have 3 jobs that run on the mainframe 
that all 3 initiate an FTP process to Windows servers.  Between the 
3 jobs they are pushing between 1.5 and 2 terabytes to the 
servers.  The jobs are currently single threaded and from looking 
at the FTP output, they are pushing the Ethernet adapter that is in 
use at 100%.  My question is this: If I configure the second 
adapter, is there a way that I can force one of these jobs to use 
one of the OSA 

Re: FTP client question

[Steve Thompson]

I have a question about the alternating of packets.

If one is using an MFT product with encryption and hand-shakes, 
will the alternating packets between routes not cause the 
"connection" and data xfer(s) to fail?


I'm asking because I know just enough about Network traffic to be 
truly dangerous -- which means I know how to specify an IP 
address and port#, and not much more.


Steve Thompson

On 5/26/2023 11:25 AM, John S. Giltner, Jr. wrote:

z/OS can do load balancing if you have mutiple equal cost routes defined, one 
route for each OSA and I think they could be the same route, something like:

 BeginRoutes

 route default =  OSA_INTERFACE1
 route default =  OSA_INTERFACE2

  ENDRoutes

You could use either default, or code routes for specific hosts/subnets.  Using 
default will load balance all outbound traffic, coding more specific routes 
will just load blance the traffic for hosts matching those routes.

You then add add one of the following statements to your IPCONFIG  statement.

   MULTIPATH PERCONNECTION

   MULTIPATH PERPACKET

First one will have z/OS alternate which route it takes per TCP connection.  
Connection request #1 get path/route #1, request #2 gets path/route #2.  
Depending on timing all 3 jobs could still get sent out the same OSA, but you 
will be using both OSA's so it won't impact all traffic.

Second one does the same thing, but per packet.  More overhead but both OSA's will be 
used "equally".

No matter what you do, depending on your network setup either one of these or, 
as Keith suggested, defining a ROUTE via a specific Interface you could 
overload your network. If your whole infrastructure is 1 Gbps Ethernet, your 
z/OS system can now push ~2 Gbps through the network.


On Thu, 25 May 2023 19:37:10 +0100, Keith Gooding  wrote:


Hi Rex

Networking is not my speciality but you should be able to add a HOST route - 
see the BEGINROUTES statement in IP Config Reference. Something like this:

ROUTE windows server IP address.  HOST   =   OSA_INTERFACE2

where OSA_INTERFACE2 is the interface which you want to use.

This example assumes that the server is on the same subnet as the adapter - 
change - to the router IP address if not.

No guarantees.

Keith Gooding

Sent from my iPad


On 25 May 2023, at 16:41, Pommier, Rex  wrote:

Hi all,

I have a question about routing FTP traffic.  First a bit about the 
environment.  Z14-zr1 with (2) 1-GbE OSA adapters shared across 3 LPARs.  The 2 
adapters are not in a VIPA configuration.  Right now on this LPAR, only 1 of 
the adapters is defined to TCP/IP.  I can easily get the second OSA configured 
into TCP/IP on the LPAR so that's not an issue.

The situation/question.  I have 3 jobs that run on the mainframe that all 3 
initiate an FTP process to Windows servers.  Between the 3 jobs they are 
pushing between 1.5 and 2 terabytes to the servers.  The jobs are currently 
single threaded and from looking at the FTP output, they are pushing the 
Ethernet adapter that is in use at 100%.  My question is this: If I configure 
the second adapter, is there a way that I can force one of these jobs to use 
one of the OSA adapters and the other 2 to go to the second adapter?  From what 
I recall, z/OS doesn't do any kind of trunking or load balancing so setting up 
a VIPA won't improve throughput by using both adapters.   I've meandered 
through the IP configuration reference and see nothing that would give me this 
capability.

TIA

Rex

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,

Re: FTP client question

[John S. Giltner, Jr.]

z/OS can do load balancing if you have mutiple equal cost routes defined, one 
route for each OSA and I think they could be the same route, something like:

BeginRoutes

route default =  OSA_INTERFACE1
route default =  OSA_INTERFACE2

 ENDRoutes

You could use either default, or code routes for specific hosts/subnets.  Using 
default will load balance all outbound traffic, coding more specific routes 
will just load blance the traffic for hosts matching those routes.

You then add add one of the following statements to your IPCONFIG  statement.

  MULTIPATH PERCONNECTION

  MULTIPATH PERPACKET

First one will have z/OS alternate which route it takes per TCP connection.  
Connection request #1 get path/route #1, request #2 gets path/route #2.  
Depending on timing all 3 jobs could still get sent out the same OSA, but you 
will be using both OSA's so it won't impact all traffic.

Second one does the same thing, but per packet.  More overhead but both OSA's 
will be used "equally".  

No matter what you do, depending on your network setup either one of these or, 
as Keith suggested, defining a ROUTE via a specific Interface you could 
overload your network. If your whole infrastructure is 1 Gbps Ethernet, your 
z/OS system can now push ~2 Gbps through the network.


On Thu, 25 May 2023 19:37:10 +0100, Keith Gooding  wrote:

>Hi Rex
>
>Networking is not my speciality but you should be able to add a HOST route - 
>see the BEGINROUTES statement in IP Config Reference. Something like this:
>
>ROUTE windows server IP address.  HOST   =   OSA_INTERFACE2
>
>where OSA_INTERFACE2 is the interface which you want to use.
>
>This example assumes that the server is on the same subnet as the adapter - 
>change - to the router IP address if not.
>
>No guarantees.
>
>Keith Gooding
>
>Sent from my iPad
>
>> On 25 May 2023, at 16:41, Pommier, Rex  wrote:
>> 
>> Hi all,
>> 
>> I have a question about routing FTP traffic.  First a bit about the 
>> environment.  Z14-zr1 with (2) 1-GbE OSA adapters shared across 3 LPARs.  
>> The 2 adapters are not in a VIPA configuration.  Right now on this LPAR, 
>> only 1 of the adapters is defined to TCP/IP.  I can easily get the second 
>> OSA configured into TCP/IP on the LPAR so that's not an issue.  
>> 
>> The situation/question.  I have 3 jobs that run on the mainframe that all 3 
>> initiate an FTP process to Windows servers.  Between the 3 jobs they are 
>> pushing between 1.5 and 2 terabytes to the servers.  The jobs are currently 
>> single threaded and from looking at the FTP output, they are pushing the 
>> Ethernet adapter that is in use at 100%.  My question is this: If I 
>> configure the second adapter, is there a way that I can force one of these 
>> jobs to use one of the OSA adapters and the other 2 to go to the second 
>> adapter?  From what I recall, z/OS doesn't do any kind of trunking or load 
>> balancing so setting up a VIPA won't improve throughput by using both 
>> adapters.   I've meandered through the IP configuration reference and see 
>> nothing that would give me this capability.  
>> 
>> TIA
>> 
>> Rex
>> 
>> --
>> The information contained in this message is confidential, protected from 
>> disclosure and may be legally privileged. If the reader of this message is 
>> not the intended recipient or an employee or agent responsible for 
>> delivering this message to the intended recipient, you are hereby notified 
>> that any disclosure, distribution, copying, or any action taken or action 
>> omitted in reliance on it, is strictly prohibited and may be unlawful. If 
>> you have received this communication in error, please notify us immediately 
>> by replying to this message and destroy the material in its entirety, 
>> whether in electronic or hard copy format. Thank you.
>> 
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: FTP client question

[Keith Gooding]

Hi Rex

Networking is not my speciality but you should be able to add a HOST route - 
see the BEGINROUTES statement in IP Config Reference. Something like this:

ROUTE windows server IP address.  HOST   =   OSA_INTERFACE2

where OSA_INTERFACE2 is the interface which you want to use.

This example assumes that the server is on the same subnet as the adapter - 
change - to the router IP address if not.

No guarantees.

Keith Gooding

Sent from my iPad

> On 25 May 2023, at 16:41, Pommier, Rex  wrote:
> 
> Hi all,
> 
> I have a question about routing FTP traffic.  First a bit about the 
> environment.  Z14-zr1 with (2) 1-GbE OSA adapters shared across 3 LPARs.  The 
> 2 adapters are not in a VIPA configuration.  Right now on this LPAR, only 1 
> of the adapters is defined to TCP/IP.  I can easily get the second OSA 
> configured into TCP/IP on the LPAR so that's not an issue.  
> 
> The situation/question.  I have 3 jobs that run on the mainframe that all 3 
> initiate an FTP process to Windows servers.  Between the 3 jobs they are 
> pushing between 1.5 and 2 terabytes to the servers.  The jobs are currently 
> single threaded and from looking at the FTP output, they are pushing the 
> Ethernet adapter that is in use at 100%.  My question is this: If I configure 
> the second adapter, is there a way that I can force one of these jobs to use 
> one of the OSA adapters and the other 2 to go to the second adapter?  From 
> what I recall, z/OS doesn't do any kind of trunking or load balancing so 
> setting up a VIPA won't improve throughput by using both adapters.   I've 
> meandered through the IP configuration reference and see nothing that would 
> give me this capability.  
> 
> TIA
> 
> Rex
> 
> --
> The information contained in this message is confidential, protected from 
> disclosure and may be legally privileged. If the reader of this message is 
> not the intended recipient or an employee or agent responsible for delivering 
> this message to the intended recipient, you are hereby notified that any 
> disclosure, distribution, copying, or any action taken or action omitted in 
> reliance on it, is strictly prohibited and may be unlawful. If you have 
> received this communication in error, please notify us immediately by 
> replying to this message and destroy the material in its entirety, whether in 
> electronic or hard copy format. Thank you.
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

FTP client question

[Pommier, Rex]

Hi all,

I have a question about routing FTP traffic.  First a bit about the 
environment.  Z14-zr1 with (2) 1-GbE OSA adapters shared across 3 LPARs.  The 2 
adapters are not in a VIPA configuration.  Right now on this LPAR, only 1 of 
the adapters is defined to TCP/IP.  I can easily get the second OSA configured 
into TCP/IP on the LPAR so that's not an issue.  

The situation/question.  I have 3 jobs that run on the mainframe that all 3 
initiate an FTP process to Windows servers.  Between the 3 jobs they are 
pushing between 1.5 and 2 terabytes to the servers.  The jobs are currently 
single threaded and from looking at the FTP output, they are pushing the 
Ethernet adapter that is in use at 100%.  My question is this: If I configure 
the second adapter, is there a way that I can force one of these jobs to use 
one of the OSA adapters and the other 2 to go to the second adapter?  From what 
I recall, z/OS doesn't do any kind of trunking or load balancing so setting up 
a VIPA won't improve throughput by using both adapters.   I've meandered 
through the IP configuration reference and see nothing that would give me this 
capability.  

TIA

Rex

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: axway for ftp

[Michael Babcock]

We have an Axway server as well.  It’s basically a FTP client/server if I
understand correctly.We don’t use it for FTPing to IBM though.   At one
time, there was a 4GB (could have been 2GB) limit on file sizes it could
transfer.   Not sure if that limitation still exists.

On Tue, Mar 14, 2023 at 5:09 AM Bill Giannelli 
wrote:

> We have axway, and have been told to use it for FTP.
> I am trying to send doc to IBM and just need to FTP (or ftps).
> What does axway do exactly?
> thanks
> Bill
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Michael Babcock
OneMain Financial
z/OS Systems Programmer, Lead

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

axway for ftp

[Bill Giannelli]

We have axway, and have been told to use it for FTP.
I am trying to send doc to IBM and just need to FTP (or ftps).
What does axway do exactly?
thanks
Bill

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can you connect to the PTF download site with z/OS FTP?

[Ed Jaffe]

On 2/28/2023 1:11 PM, Paul Gilmartin wrote:


Have you an example of a customer-facing (public) IBM SFTP server?


All IBM servers where I have tried SFTP worked as expected.

Here are two examples:

: >sftp testcase.boulder.ibm.com
FOTS1754 Password Authentication
FOTS1754 Enter password for EDJXADM
Password:
CEE5205S The signal SIGTERM was received.
: >sftp public.dhe.ibm.com
The authenticity of host 'public.dhe.ibm.com (170.225.126.18)' can't be 
established.

ECDSA key fingerprint is SHA256:4FVL8LYyueaAzmwaSj+/fmxttFyQHGI00ohwfM/jNWU.
Are you sure you want to continue connecting (yes/no)? CEE5205S The 
signal SIGTERM was received.

EDJXADM:/u/edjxadm: >

Obviously, I have used the first one before (many times in fact).

This was the first time trying for the second one (the one to which 
Charles is connecting)...


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can you connect to the PTF download site with z/OS FTP?

[Paul Gilmartin]

On Tue, 28 Feb 2023 09:29:39 -0800, Ed Jaffe wrote:
>
>Paul Gorlinski mentioned SFTP without also mentioning FTPS, and now
>you've mentioned FTPS without mentioning SFTP.
>
>In my experience, both of those FTP-based protocols work as expected
>with IBM's customer-facing servers.
>
I don't perceive SFTP. as  FTP-based.  Rather, it's ssh-based with a
command syntax resembling FTP, even as "jar" is not tar-based but
zip-based with a command syntax resembling "tar".

Have you an example of a customer-facing (public) IBM SFTP server?

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can you connect to the PTF download site with z/OS FTP?

[Ed Jaffe]

On 2/28/2023 5:36 AM, Allan Staller wrote:

Classification: Confidential

IBM made a change to no longer accept non-secured connections due to some EU 
privacy laws. IIRC July 2021 or so. HTTPS or FTPS is required.
I do not know if AT-TLS is one of the accepted protocols.


Paul Gorlinski mentioned SFTP without also mentioning FTPS, and now 
you've mentioned FTPS without mentioning SFTP.


In my experience, both of those FTP-based protocols work as expected 
with IBM's customer-facing servers.


AT-TLS is not a protocol. It is the way z/OS enables its applications to 
use secure internet protocols without the developers having to 
explicitly add support to them.



--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can you connect to the PTF download site with z/OS FTP?

[Wendell Lovewell]

Generally speaking (I don't know about IBM support) you can get the FTP client 
to connect via TLS 1.2 without using AT-TLS if you specify the right settings.  
But you'll still need the certificates added to a RACF keyring. 

//*---
//FTPS EXEC PGM=FTP,REGION=4M,
// PARM=('ENVAR("_CEE_ENVFILE_S=DD:STDENV")/ftp.whatever.com 21 -e')
//STDENV   DD *
GSK_PROTOCOL_TLSV1_2=ON
//* GSK_TRACE=0x
//* GSK_TRACE_FILE=/tmp/gsk.trc
//* The 2 stmts above can be temporarily uncommented for debugging
//SYSFTPD  DD *,SYMBOLS=(JCLONLY)
CLIENTERRCODESEXTENDED
EPSV4 TRUE
EXTENSIONSAUTH_TLS
FWFRIENDLYTRUE
KEYRING   /
PASSIVEIGNOREADDR TRUE
SECUREIMPLICITZOS FALSE
SECURE_FTPREQUIRED
SECURE_MECHANISM  TLS
SECURE_DATACONN   PRIVATE
SECURE_CTRLCONN   PRIVATE
SECURE_HOSTNAME   REQUIRED
TLSMECHANISM  FTP
TLSRFCLEVEL   RFC4217
//* DEBUG SEC
//* TRACE
//* The 2 stmts above can be temporarily uncommented for debugging
//*

This worked on z/OS 2.4 and 2.5.  Maybe earlier. 

If you capture the trace, you'll need to use the gsktrace command to decipher 
it: 
gsktrace /tmp/gsk.trc > /tmp/gsk.out

"DEBUG" and "TRACE" are just routed to SYSOUT, so they're easier.  But there is 
a lot of information on the key exchange in the gsk trace. 

Wendell

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can you connect to the PTF download site with z/OS FTP?

[Allan Staller]

Classification: Confidential

Thnks for the update Kurt.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Kurt J. Quackenbush
Sent: Tuesday, February 28, 2023 7:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can you connect to the PTF download site with z/OS FTP?

[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.]

IBM Downloads (public.dhe.ibm.com) - Disablement of unsecure connection methods:
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fpages%2Fnode%2F6826677=05%7C01%7Callan.staller%40HCL.COM%7C335a4bc446a643d7735e08db1993a5c0%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C638131894168252828%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=tHegNJsGnJUn%2FGLfL1rxrkbxuPxoJzo9BGOaCMO4s7o%3D=0

Kurt Quackenbush
IBM  |  z/OS SMP/E and z/OSMF Software Management  |  ku...@us.ibm.com

Chuck Norris never uses CHECK when he applies PTFs.

--
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

Re: Can you connect to the PTF download site with z/OS FTP?

[Kurt J. Quackenbush]

IBM Downloads (public.dhe.ibm.com) - Disablement of unsecure connection methods:
https://www.ibm.com/support/pages/node/6826677

Kurt Quackenbush
IBM  |  z/OS SMP/E and z/OSMF Software Management  |  ku...@us.ibm.com

Chuck Norris never uses CHECK when he applies PTFs.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can you connect to the PTF download site with z/OS FTP?

[Allan Staller]

Classification: Confidential

IBM made a change to no longer accept non-secured connections due to some EU 
privacy laws. IIRC July 2021 or so. HTTPS or FTPS is required.
I do not know if AT-TLS is one of the accepted protocols.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Michael Babcock
Sent: Monday, February 27, 2023 6:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can you connect to the PTF download site with z/OS FTP?

[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.]

We have been using plain old FTP to IBM (downloading enhanced hold data) for 
quite a while now and in the last week or so, we had to convert to
using FTPS (TLS 1.2).   So to me, it appears IBM made a change and now
requires a secure connection.   Yes, I know we can use SMPE RECEIVE ORDER,
and we do but we had a STEP in one of our jobs that used the old way.

On Mon, Feb 27, 2023 at 6:24 PM Charles Mills  wrote:

> FWIW what you show is in conflict with what Paul Gorlinsky wrote: that
> IBM did not support FTPS.
>
> (I'm not trying to pick a fight. I have reasons for wanting to get
> FTPS to
> work.)
>
> I see that you are using AT-TLS and that is goodness of course but it
> should not make a huge difference bottom line. I wonder why mine is failing.
>
> At least I know the problem is not V2R5. That's a help.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Ed Jaffe
> Sent: Monday, February 27, 2023 10:38 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Can you connect to the PTF download site with z/OS FTP?
>
> On 2/27/2023 9:32 AM, Charles Mills wrote:
> >
> > Starting I think with V2R5 you need AT-TLS for the FTP server, and
> > for
> TLS 1.3 (only) on the client.
>
> Don't know about TLS 1.3 (we don't use that yet), but it clearly still
> supports TLS 1.2. See below:
>
> EZA1450I IBM FTP CS V2R5
> EZA1466I FTP: using TCPIP
> EZA1456I Connect to ?
> EZA1736I public.dhe.ibm.com
> EZYFT18I Using catalog '/usr/lib/nls/msg/C/ftpdmsg.cat' for FTP messages.
> EZA1554I Connecting to: public.southdata.ibm.com 170.225.126.18 port: 21.
> 220-**
>   **
>   *  IBM's internal systems must only be used for conducting IBM's *
>   *  business or for purposes authorized by IBM management.*
>   **
>   *  Use is subject to audit at any time by IBM management.*
>   **
>   *  Important  Please read*
>   **
>   *  Machine Code updates provided through this site are available *
>   *  only for IBM machines that are under warranty or an IBM hardware  *
>   *  maintenance service agreement Code for operating systems or other *
>   *  software products is available only where entitled under the  *
>   *  applicable software warranty or IBM software maintenance  *
>   *  agreement. All code (including Machine Code updates, samples, *
>   *  fixes or other software downloads)provided through this site  *
>   *  is subject to the terms of the license agreements which   *
>   *  govern the use of the associated code. Some exceptions may*
>   *  apply.IBM reserves the right to change, modify or withdraw its*
>   *  offerings,policies and practices at any time. *
>
> **
> 220 ProFTPD Server (proftpd) [170.225.126.18]
> FC0296 ftpAuth: security values: mech=TLS, tlsmech=ATTLS, tlsreuse=N,
> sFTP=A, sCC=C, sDC=P
> FC2975 ftpAuthAttls: AT-TLS policy set as application controlled.
> FU2420 TTLSRule: PSI_FTP-Client~1
> FU2426 TTLSGroupAction: gAct1
> FU2432 TTLSEnvironmentAction: eAct1~FTP_Clients
> FU2439 TTLSConnectionACtion: cAct1~FTP_Clients EZA1701I >>> AUTH TLS
> 234 AUTH TLS successful
> FC3144 authServerAttls: Start Handshake
> FC3175 authServerAttls: FIPS140 not enabled
> FC3212 authServerAttls: Using TLSv1.2 protocol
> FC3230 authServerAttls: SSL cipher: 002F
> FU2135 getCtrlConnCertAttls: Request certificate, size 1751
> FU2755 getSessionIdAttls: Issuing SIOCTTLSCTL to get decoded AT-TLS
> Session ID EZA2895I Authentication negotiation succeeded
>
> -

Re: Can you connect to the PTF download site with z/OS FTP?

[Michael Babcock]

We have been using plain old FTP to IBM (downloading enhanced hold data)
for quite a while now and in the last week or so, we had to convert to
using FTPS (TLS 1.2).   So to me, it appears IBM made a change and now
requires a secure connection.   Yes, I know we can use SMPE RECEIVE ORDER,
and we do but we had a STEP in one of our jobs that used the old way.

On Mon, Feb 27, 2023 at 6:24 PM Charles Mills  wrote:

> FWIW what you show is in conflict with what Paul Gorlinsky wrote: that IBM
> did not support FTPS.
>
> (I'm not trying to pick a fight. I have reasons for wanting to get FTPS to
> work.)
>
> I see that you are using AT-TLS and that is goodness of course but it
> should not make a huge difference bottom line. I wonder why mine is failing.
>
> At least I know the problem is not V2R5. That's a help.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Ed Jaffe
> Sent: Monday, February 27, 2023 10:38 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Can you connect to the PTF download site with z/OS FTP?
>
> On 2/27/2023 9:32 AM, Charles Mills wrote:
> >
> > Starting I think with V2R5 you need AT-TLS for the FTP server, and for
> TLS 1.3 (only) on the client.
>
> Don't know about TLS 1.3 (we don't use that yet), but it clearly still
> supports TLS 1.2. See below:
>
> EZA1450I IBM FTP CS V2R5
> EZA1466I FTP: using TCPIP
> EZA1456I Connect to ?
> EZA1736I public.dhe.ibm.com
> EZYFT18I Using catalog '/usr/lib/nls/msg/C/ftpdmsg.cat' for FTP messages.
> EZA1554I Connecting to: public.southdata.ibm.com 170.225.126.18 port: 21.
> 220-**
>   **
>   *  IBM's internal systems must only be used for conducting IBM's *
>   *  business or for purposes authorized by IBM management.*
>   **
>   *  Use is subject to audit at any time by IBM management.*
>   **
>   *  Important  Please read*
>   **
>   *  Machine Code updates provided through this site are available *
>   *  only for IBM machines that are under warranty or an IBM hardware  *
>   *  maintenance service agreement Code for operating systems or other *
>   *  software products is available only where entitled under the  *
>   *  applicable software warranty or IBM software maintenance  *
>   *  agreement. All code (including Machine Code updates, samples, *
>   *  fixes or other software downloads)provided through this site  *
>   *  is subject to the terms of the license agreements which   *
>   *  govern the use of the associated code. Some exceptions may*
>   *  apply.IBM reserves the right to change, modify or withdraw its*
>   *  offerings,policies and practices at any time. *
>   **
> 220 ProFTPD Server (proftpd) [170.225.126.18]
> FC0296 ftpAuth: security values: mech=TLS, tlsmech=ATTLS, tlsreuse=N,
> sFTP=A, sCC=C, sDC=P
> FC2975 ftpAuthAttls: AT-TLS policy set as application controlled.
> FU2420 TTLSRule: PSI_FTP-Client~1
> FU2426 TTLSGroupAction: gAct1
> FU2432 TTLSEnvironmentAction: eAct1~FTP_Clients
> FU2439 TTLSConnectionACtion: cAct1~FTP_Clients EZA1701I >>> AUTH TLS
> 234 AUTH TLS successful
> FC3144 authServerAttls: Start Handshake
> FC3175 authServerAttls: FIPS140 not enabled
> FC3212 authServerAttls: Using TLSv1.2 protocol
> FC3230 authServerAttls: SSL cipher: 002F
> FU2135 getCtrlConnCertAttls: Request certificate, size 1751
> FU2755 getSessionIdAttls: Issuing SIOCTTLSCTL to get decoded AT-TLS
> Session ID EZA2895I Authentication negotiation succeeded
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Michael Babcock
OneMain Financial
z/OS Systems Programmer, Lead

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can you connect to the PTF download site with z/OS FTP?

[Charles Mills]

FWIW what you show is in conflict with what Paul Gorlinsky wrote: that IBM did 
not support FTPS.

(I'm not trying to pick a fight. I have reasons for wanting to get FTPS to 
work.)

I see that you are using AT-TLS and that is goodness of course but it should 
not make a huge difference bottom line. I wonder why mine is failing.

At least I know the problem is not V2R5. That's a help.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Monday, February 27, 2023 10:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can you connect to the PTF download site with z/OS FTP?

On 2/27/2023 9:32 AM, Charles Mills wrote:
>
> Starting I think with V2R5 you need AT-TLS for the FTP server, and for TLS 
> 1.3 (only) on the client.

Don't know about TLS 1.3 (we don't use that yet), but it clearly still supports 
TLS 1.2. See below:

EZA1450I IBM FTP CS V2R5
EZA1466I FTP: using TCPIP
EZA1456I Connect to ?
EZA1736I public.dhe.ibm.com
EZYFT18I Using catalog '/usr/lib/nls/msg/C/ftpdmsg.cat' for FTP messages.
EZA1554I Connecting to: public.southdata.ibm.com 170.225.126.18 port: 21.
220-**
  **
  *  IBM's internal systems must only be used for conducting IBM's *
  *  business or for purposes authorized by IBM management.*
  **
  *  Use is subject to audit at any time by IBM management.*
  **
  *  Important  Please read*
  **
  *  Machine Code updates provided through this site are available *
  *  only for IBM machines that are under warranty or an IBM hardware  *
  *  maintenance service agreement Code for operating systems or other *
  *  software products is available only where entitled under the  *
  *  applicable software warranty or IBM software maintenance  *
  *  agreement. All code (including Machine Code updates, samples, *
  *  fixes or other software downloads)provided through this site  *
  *  is subject to the terms of the license agreements which   *
  *  govern the use of the associated code. Some exceptions may*
  *  apply.IBM reserves the right to change, modify or withdraw its*
  *  offerings,policies and practices at any time. *
  **
220 ProFTPD Server (proftpd) [170.225.126.18]
FC0296 ftpAuth: security values: mech=TLS, tlsmech=ATTLS, tlsreuse=N, sFTP=A, 
sCC=C, sDC=P
FC2975 ftpAuthAttls: AT-TLS policy set as application controlled.
FU2420 TTLSRule: PSI_FTP-Client~1
FU2426 TTLSGroupAction: gAct1
FU2432 TTLSEnvironmentAction: eAct1~FTP_Clients
FU2439 TTLSConnectionACtion: cAct1~FTP_Clients EZA1701I >>> AUTH TLS
234 AUTH TLS successful
FC3144 authServerAttls: Start Handshake
FC3175 authServerAttls: FIPS140 not enabled
FC3212 authServerAttls: Using TLSv1.2 protocol
FC3230 authServerAttls: SSL cipher: 002F
FU2135 getCtrlConnCertAttls: Request certificate, size 1751
FU2755 getSessionIdAttls: Issuing SIOCTTLSCTL to get decoded AT-TLS Session ID 
EZA2895I Authentication negotiation succeeded

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can you connect to the PTF download site with z/OS FTP?

[Ed Jaffe]

On 2/27/2023 9:32 AM, Charles Mills wrote:


Starting I think with V2R5 you need AT-TLS for the FTP server, and for TLS 1.3 
(only) on the client.


Don't know about TLS 1.3 (we don't use that yet), but it clearly still 
supports TLS 1.2. See below:


EZA1450I IBM FTP CS V2R5
EZA1466I FTP: using TCPIP
EZA1456I Connect to ?
EZA1736I public.dhe.ibm.com
EZYFT18I Using catalog '/usr/lib/nls/msg/C/ftpdmsg.cat' for FTP messages.
EZA1554I Connecting to: public.southdata.ibm.com 170.225.126.18 port: 21.
220-**
 *    *
 *  IBM's internal systems must only be used for conducting IBM's *
 *  business or for purposes authorized by IBM management.    *
 *    *
 *  Use is subject to audit at any time by IBM management.    *
 *    *
 *  Important  Please read    *
 *    *
 *  Machine Code updates provided through this site are available *
 *  only for IBM machines that are under warranty or an IBM hardware  *
 *  maintenance service agreement Code for operating systems or other *
 *  software products is available only where entitled under the  *
 *  applicable software warranty or IBM software maintenance  *
 *  agreement. All code (including Machine Code updates, samples, *
 *  fixes or other software downloads)provided through this site  *
 *  is subject to the terms of the license agreements which   *
 *  govern the use of the associated code. Some exceptions may    *
 *  apply.IBM reserves the right to change, modify or withdraw its    *
 *  offerings,policies and practices at any time. *
 **
220 ProFTPD Server (proftpd) [170.225.126.18]
FC0296 ftpAuth: security values: mech=TLS, tlsmech=ATTLS, tlsreuse=N, 
sFTP=A, sCC=C, sDC=P

FC2975 ftpAuthAttls: AT-TLS policy set as application controlled.
FU2420 TTLSRule: PSI_FTP-Client~1
FU2426 TTLSGroupAction: gAct1
FU2432 TTLSEnvironmentAction: eAct1~FTP_Clients
FU2439 TTLSConnectionACtion: cAct1~FTP_Clients
EZA1701I >>> AUTH TLS
234 AUTH TLS successful
FC3144 authServerAttls: Start Handshake
FC3175 authServerAttls: FIPS140 not enabled
FC3212 authServerAttls: Using TLSv1.2 protocol
FC3230 authServerAttls: SSL cipher: 002F
FU2135 getCtrlConnCertAttls: Request certificate, size 1751
FU2755 getSessionIdAttls: Issuing SIOCTTLSCTL to get decoded AT-TLS 
Session ID

EZA2895I Authentication negotiation succeeded


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can you connect to the PTF download site with z/OS FTP?

[Keith Gooding]

The download server supports FTP over SSL (FTPS) and HTTPS. See SMP/E User 
guide Zos 2.5 section “Preparing for secure Internet delivery”. That document 
states that you need at-tls because Tls 1.2 is used. This would be for pts 
ordering and download via SMP/E. When I have ordered PTFs outside of SMP/E the 
delivery package always included sample jobs for https or FTPs download. 

> On 27 Feb 2023, at 17:33, Paul Gilmartin 
> <042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On Mon, 27 Feb 2023 10:54:33 -0600, Charles Mills wrote:
> 
>> Just to confirm, by that you mean "SSH FTP" only, and that "FTP over TLS" is 
>> not supported.
>> 
> FWIW, from a desktop system:
>1029 $ sftp public.dhe.ibm.com
>The authenticity of host 'public.dhe.ibm.com (170.225.126.18)' can't be 
> established.
>ED25519 key fingerprint is 
> SHA256:7eCHKMY8cjRJ7vM2NU70s9ETBNSWGYu4/BTCL2q4rCM.
>This key is not known by any other names
>Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
>Warning: Permanently added 'public.dhe.ibm.com' (ED25519) to the list of 
> known hosts.
>(g...@public.dhe.ibm.com) gil's Password:
> 
> ???
> 
>> (The confusingly similar acronyms SFTP and FTPS are unfortunate.)
>> 
> The English language and its acronyms abound with anagrams.  Pointless to
> complain.
> 
> Rather, complain to IBM about its depending on the increasingly obsolete FTP.
> Cbttape.org got better.  So should IBM; provide an HTTPS proxy, if necessary.
> 
> -- 
> gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can you connect to the PTF download site with z/OS FTP?

[Paul Gilmartin]

On Mon, 27 Feb 2023 10:54:33 -0600, Charles Mills wrote:

>Just to confirm, by that you mean "SSH FTP" only, and that "FTP over TLS" is 
>not supported.
>
FWIW, from a desktop system:
1029 $ sftp public.dhe.ibm.com
The authenticity of host 'public.dhe.ibm.com (170.225.126.18)' can't be 
established.
ED25519 key fingerprint is 
SHA256:7eCHKMY8cjRJ7vM2NU70s9ETBNSWGYu4/BTCL2q4rCM.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'public.dhe.ibm.com' (ED25519) to the list of 
known hosts.
(g...@public.dhe.ibm.com) gil's Password:

???

>(The confusingly similar acronyms SFTP and FTPS are unfortunate.)
>
The English language and its acronyms abound with anagrams.  Pointless to
complain.

Rather, complain to IBM about its depending on the increasingly obsolete FTP.
Cbttape.org got better.  So should IBM; provide an HTTPS proxy, if necessary.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can you connect to the PTF download site with z/OS FTP?

[Charles Mills]

> What release of z/OS are you using?

Tried on both V2R4 and V2R5 with identical (at least superficially) results.

> ISTR starting with z/OS 2.4 you must use AT-TLS for secure FTP.

Starting I think with V2R5 you need AT-TLS for the FTP server, and for TLS 1.3 
(only) on the client. 

https://www.ibm.com/docs/en/zos/2.5.0?topic=protocol-tlsmechanism-ftp-client-server-statement
 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Monday, February 27, 2023 8:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Can you connect to the PTF download site with z/OS FTP?

On 2/27/2023 7:16 AM, Charles Mills wrote:
> I am trying to connect to public.dhe.ibm.com using z/OS FTP. No matter what I 
> do, the session fails with
>
> FC1108 authServer: secure_socket_init failed with rc = 410 (SSL message 
> format is incorrect)

What release of z/OS are you using?

ISTR starting with z/OS 2.4 you must use AT-TLS for secure FTP.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Can you connect to the PTF download site with z/OS FTP?

[Ed Jaffe]

On 2/27/2023 7:16 AM, Charles Mills wrote:

I am trying to connect to public.dhe.ibm.com using z/OS FTP. No matter what I 
do, the session fails with

FC1108 authServer: secure_socket_init failed with rc = 410 (SSL message format 
is incorrect)


What release of z/OS are you using?

ISTR starting with z/OS 2.4 you must use AT-TLS for secure FTP.

Therefore, your FTPDATA needs:

EXTENSIONS    AUTH_TLS
SECURE_DATACONN   PRIVATE
SECURE_MECHANISM  TLS
TLSMECHANISM  ATTLS

and you must also have the supporting setup for AT-TLS via the PAGENT 
address space.


If this seems daunting, it might be easier to use SFTP via OPENSSH on 
z/OS. It's a good deal simpler to set up, but does not support sending 
or receiving classic MVS data sets. It supports z/OS UNIX files only. 
There is Co:Z from Dovetailed if you want that capability...



--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN