So... a client has a system, the data folks key in their data and when
they're done they click an icon on their desktops.

The icon invokes an ftp session and sends the data to a server. After the
data are sent a .txt file of JCL, filetype=JES.

The big iron sweeps the server (CONTROL-M), grabs the data and then sends
the JES to the INTRDR. This kicks off procs that run programs that I
wrote back when years began with 19 and all goes well.

The supplier of mainframe services has said 'ftp? horrors, port 21 must be
closed and everything needs to go to port 22'...

.... and the supplier can't get it right. Every time they send a file from
the server to a dataset on the mainframe 'it comes out garbage'.

I sat in on a conference call yesterday and heard 'the best us suppliers
can do is turn a process that's run with no intervention for 30 years into
something that needs someone to manually log on and submit jubs.'

My unspoken response was 'Hogwash. Someone's done this before and
their work has been incorporated into documentation, somewhere.'

I've been slogging through the z/OS Linux manuals and I've found the OGET
documentation. I'm starting to get a feeling that a certification or a
key or the like needs to be installed.

If someone's kind enough to offer a suggestion or so generous as to say
'Why, I remember when we did that at Drexel, Burham Lambert, it went kind
of like this...' I'd be much obliged.

DD

On 9/8/2023 9:08 AM, docdwarf@panix.com wrote:
> So... a client has a system, the data folks key in their data and when
> they're done they click an icon on their desktops.
>
> The icon invokes an ftp session and sends the data to a server. After the
> data are sent a .txt file of JCL, filetype=JES.
>
> The big iron sweeps the server (CONTROL-M), grabs the data and then sends
> the JES to the INTRDR. This kicks off procs that run programs that I
> wrote back when years began with 19 and all goes well.
>
> The supplier of mainframe services has said 'ftp? horrors, port 21 must be
> closed and everything needs to go to port 22'...
>
> ... and the supplier can't get it right. Every time they send a file from
> the server to a dataset on the mainframe 'it comes out garbage'.
>
> I sat in on a conference call yesterday and heard 'the best us suppliers
> can do is turn a process that's run with no intervention for 30 years into
> something that needs someone to manually log on and submit jubs.'
>
> My unspoken response was 'Hogwash. Someone's done this before and
> their work has been incorporated into documentation, somewhere.'
>
> I've been slogging through the z/OS Linux manuals and I've found the OGET
> documentation. I'm starting to get a feeling that a certification or a
> key or the like needs to be installed.
>
> If someone's kind enough to offer a suggestion or so generous as to say
> 'Why, I remember when we did that at Drexel, Burham Lambert, it went kind
> of like this...' I'd be much obliged.
>
> DD

SFTP?

bill

In article <km0m1oF8emlU4@mid.individual.net>,
bill <bill.gunshannon@gmail.com> wrote:
>On 9/8/2023 9:08 AM, docdwarf@panix.com wrote:
>> So... a client has a system, the data folks key in their data and when
>> they're done they click an icon on their desktops.
>>
>> The icon invokes an ftp session and sends the data to a server. After the
>> data are sent a .txt file of JCL, filetype=JES.
>>
>> The big iron sweeps the server (CONTROL-M), grabs the data and then sends
>> the JES to the INTRDR. This kicks off procs that run programs that I
>> wrote back when years began with 19 and all goes well.
>>
>> The supplier of mainframe services has said 'ftp? horrors, port 21 must be
>> closed and everything needs to go to port 22'...
>>
>> ... and the supplier can't get it right. Every time they send a file from
>> the server to a dataset on the mainframe 'it comes out garbage'.
>>
>> I sat in on a conference call yesterday and heard 'the best us suppliers
>> can do is turn a process that's run with no intervention for 30 years into
>> something that needs someone to manually log on and submit jubs.'
>>
>> My unspoken response was 'Hogwash. Someone's done this before and
>> their work has been incorporated into documentation, somewhere.'
>>
>> I've been slogging through the z/OS Linux manuals and I've found the OGET
>> documentation. I'm starting to get a feeling that a certification or a
>> key or the like needs to be installed.
>>
>> If someone's kind enough to offer a suggestion or so generous as to say
>> 'Why, I remember when we did that at Drexel, Burham Lambert, it went kind
>> of like this...' I'd be much obliged.
>
>SFTP?

No, sftp. Case sensitive.

DD

On 9/8/2023 3:27 PM, docdwarf@panix.com wrote:
> In article <km0m1oF8emlU4@mid.individual.net>,
> bill <bill.gunshannon@gmail.com> wrote:
>> On 9/8/2023 9:08 AM, docdwarf@panix.com wrote:
>>> So... a client has a system, the data folks key in their data and when
>>> they're done they click an icon on their desktops.
>>>
>>> The icon invokes an ftp session and sends the data to a server. After the
>>> data are sent a .txt file of JCL, filetype=JES.
>>>
>>> The big iron sweeps the server (CONTROL-M), grabs the data and then sends
>>> the JES to the INTRDR. This kicks off procs that run programs that I
>>> wrote back when years began with 19 and all goes well.
>>>
>>> The supplier of mainframe services has said 'ftp? horrors, port 21 must be
>>> closed and everything needs to go to port 22'...
>>>
>>> ... and the supplier can't get it right. Every time they send a file from
>>> the server to a dataset on the mainframe 'it comes out garbage'.
>>>
>>> I sat in on a conference call yesterday and heard 'the best us suppliers
>>> can do is turn a process that's run with no intervention for 30 years into
>>> something that needs someone to manually log on and submit jubs.'
>>>
>>> My unspoken response was 'Hogwash. Someone's done this before and
>>> their work has been incorporated into documentation, somewhere.'
>>>
>>> I've been slogging through the z/OS Linux manuals and I've found the OGET
>>> documentation. I'm starting to get a feeling that a certification or a
>>> key or the like needs to be installed.
>>>
>>> If someone's kind enough to offer a suggestion or so generous as to say
>>> 'Why, I remember when we did that at Drexel, Burham Lambert, it went kind
>>> of like this...' I'd be much obliged.
>>
>> SFTP?
>
> No, sftp. Case sensitive.
>
> DD

Well, sftp seems like a possible replacement option for ftp. It should
be scriptable. sftp does require a login but it does create a complete
encrypted session. Some setup on the mainframe side would be required,
for userids to login to sftp, as well as the physical connection. Most
ftp commands are identical in sftp but a few are different.

I'm not familiar with OGET. I suppose IND$FILE is too old or
unsupported (or insecure). It seems to me there were some file transfer
options in tn3270 supported by a number of 3270 Terminal Emulators.

Your supplier should really provide an upgrade path if they require you
to discontinue using ftp.

You're probably doing you own googling, but there should be lots of
information available on these subjects.

https://www.ibm.com/docs/en/zos/2.2.0?topic=systems-specifying-ftp-sftp-server-settings

https://kinsta.com/knowledgebase/ftp-vs-sftp/

https://techdifferences.com/difference-between-ftp-and-sftp.html

https://www.ibm.com/docs/en/zos/2.2.0?topic=settings-enabling-data-file-transfer-between-systems

If the only problem is that the data is corrupted, it's possible the
transfer is being done in binary (with no ASCII to EBCDIC translation).
Fixing that should be just a setting somewhere.

Good luck!

--
https://www.arnoldtrembley.com/

In article <9pycnYaRD5QRl2H5nZ2dnZfqn_adnZ2d@giganews.com>,
Arnold Trembley <arnold.trembley@att.net> wrote:
>On 9/8/2023 3:27 PM, docdwarf@panix.com wrote:
>> In article <km0m1oF8emlU4@mid.individual.net>,
>> bill <bill.gunshannon@gmail.com> wrote:
>>> On 9/8/2023 9:08 AM, docdwarf@panix.com wrote:

[snip]

>>>> I sat in on a conference call yesterday and heard 'the best us suppliers
>>>> can do is turn a process that's run with no intervention for 30 years into
>>>> something that needs someone to manually log on and submit jubs.'

[snip]

>Your supplier should really provide an upgrade path if they require you
>to discontinue using ftp.

They did, as noted above: 'do it by hand'. I have a feeling they're
hiding inabilities from their bosses by whining '... but we *told* them
*exactly* what they needed to do, we even gave them *templates* we *wrote
ourselves* that would work just fine'.

>
>You're probably doing you own googling, but there should be lots of
>information available on these subjects.
>
>https://www.ibm.com/docs/en/zos/2.2.0?topic=systems-specifying-ftp-sftp-server-settings
>
>https://kinsta.com/knowledgebase/ftp-vs-sftp/
>
>https://techdifferences.com/difference-between-ftp-and-sftp.html
>
>https://www.ibm.com/docs/en/zos/2.2.0?topic=settings-enabling-data-file-transfer-between-systems
>
>If the only problem is that the data is corrupted, it's possible the
>transfer is being done in binary (with no ASCII to EBCDIC translation).
>Fixing that should be just a setting somewhere.

Greatly approciated, Mr Trembley. As I said, I was called in on this for
the first time and last-minute. If they want me to burn some hours on it
my first request is 'it would be helpful to look at the output; please
perform your last test using the following record of data:

A B C D E F G H I J ## 0 0 2 3 4 5 6 7 8 9

.... space-padded to 80 characters. Notify me when the output's ready and
you can tell me which codepage is used.'

.... and let them learn a bit about how to debug 'data corruption' problems
between platforms and character encoding sets.

>Good luck!

Good health to you and yours, Mr Trembley.w