Re: SMPE receive order broken this morning?

[linda golding]

Set EPSV4 to OFF and give a try .

Regards,
Linda



On Fri, Aug 19, 2016 at 7:00 PM, Kurt Quackenbush  wrote:

> On 8/18/2016 10:44 AM, b...@jndata.dk wrote:
>
>> Hi'
>> We had same issue (SSL mandatory) with SMP/E Receive Order jobs this week
>> and we have corrected our jobs to recommend FTP option, so now we gets a
>> new FTP problem:
>> 
>> EZA1701I >>> RETR /2016081863489/PROD/GIMPAF.XML
>> SC2035 connDsConnection: entered
>> SC2129 connDsConnectionIPv4: entered
>> SC2297 connDsConnectionIPv4: connect() failed on socket 6, retry_conn = 0
>> - EDC8
>> 127I Connection timed out. (errno2=0x76630291)
>> SC7576 update_data_appldata: entered
>> FU1864 getNegotiatedTLSvalues: entered
>> GU5349 ftpSetApplData: entered
>> GU5361 ftpSetApplData: ioctl() failed on SIOCSAPPLDATA - EDC5113I Bad
>> file descr
>> iptor. (errno2=0x1015011C)
>> CG1980 SETCEC code = 8
>> CG1982 hfs_rcvFile: could not get a data connection
>> EZA1636I *** I can't open a data-transfer connection:
>> SC3277 getReply: entered
>> SC4343 getNextReply: entered with waitForData = TRUE
>> 425 Can't open data connection.
>> SC4035 getLastReply: entered
>> CG1499 pcgCleanup: entered
>> MF0629 seq_close_file: entered
>> MF0783 seq_close_file: file closed
>> MV2310 seq_delete_file: entered
>> MV2316 seq_delete_file: file=/u/SMPNTS/smpeauto/ORD000
>> 92-18August2016-11.32.34/G
>> IMPAF.XML
>> -
>>
>> Any hints/tips to what we are missing ???.
>>
>
> Looks to me like your firewall is getting in the way.
>
> Does any one know which ports SFTP uses compared to FTP traffic against
>> this IBM IP-dest. ??
>>
>
> It is FTPS, not sftp, and the data connection ports are not statically
> defined.  Passive FTP data connection ports on the IBM servers are defined
> as a range, I believe 65024 through 65535.
>
> Could it be Firewall changes we are missing, after changing to SFTP
>> options ??.
>>
>
> Yes, I suspect it is your firewall that is blocking the data connection.
>
> I highly recommend you try using https instead of ftps, by adding the
> following to your  specification:
>
>   downloadmethod=”https”
>   downloadkeyring=”javatruststore”
>   javahome="/usr/lpp/java/Jn.n"
>
> where javahome of course points to your installed and preferred level of
> java.  Firewalls and proxies are generally much more tolerant of https than
> they are of ftps.
>
>
> Kurt Quackenbush -- IBM, SMP/E Development
>
> --
> 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: SMPE receive order broken this morning?

[Kurt Quackenbush]

On 8/18/2016 10:44 AM, b...@jndata.dk wrote:

Hi'
We had same issue (SSL mandatory) with SMP/E Receive Order jobs this week and 
we have corrected our jobs to recommend FTP option, so now we gets a new FTP 
problem:

EZA1701I >>> RETR /2016081863489/PROD/GIMPAF.XML
SC2035 connDsConnection: entered
SC2129 connDsConnectionIPv4: entered
SC2297 connDsConnectionIPv4: connect() failed on socket 6, retry_conn = 0 - EDC8
127I Connection timed out. (errno2=0x76630291)
SC7576 update_data_appldata: entered
FU1864 getNegotiatedTLSvalues: entered
GU5349 ftpSetApplData: entered
GU5361 ftpSetApplData: ioctl() failed on SIOCSAPPLDATA - EDC5113I Bad file descr
iptor. (errno2=0x1015011C)
CG1980 SETCEC code = 8
CG1982 hfs_rcvFile: could not get a data connection
EZA1636I *** I can't open a data-transfer connection:
SC3277 getReply: entered
SC4343 getNextReply: entered with waitForData = TRUE
425 Can't open data connection.
SC4035 getLastReply: entered
CG1499 pcgCleanup: entered
MF0629 seq_close_file: entered
MF0783 seq_close_file: file closed
MV2310 seq_delete_file: entered
MV2316 seq_delete_file: file=/u/SMPNTS/smpeauto/ORD00092-18August2016-11.32.34/G
IMPAF.XML
-

Any hints/tips to what we are missing ???.


Looks to me like your firewall is getting in the way.


Does any one know which ports SFTP uses compared to FTP traffic against this 
IBM IP-dest. ??


It is FTPS, not sftp, and the data connection ports are not statically 
defined.  Passive FTP data connection ports on the IBM servers are 
defined as a range, I believe 65024 through 65535.



Could it be Firewall changes we are missing, after changing to SFTP options ??.


Yes, I suspect it is your firewall that is blocking the data connection.

I highly recommend you try using https instead of ftps, by adding the 
following to your  specification:


  downloadmethod=”https”
  downloadkeyring=”javatruststore”
  javahome="/usr/lpp/java/Jn.n"

where javahome of course points to your installed and preferred level of 
java.  Firewalls and proxies are generally much more tolerant of https 
than they are of ftps.


Kurt Quackenbush -- IBM, SMP/E Development

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

Re: SMPE receive order broken this morning?

[Jousma, David]

Thanks Kurt, you are correct, it must have been a timing thing.  I just 
reverted back to TLSMECHISM AT-TLS and it is working.

Thanks for the feedback.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kurt Quackenbush
Sent: Tuesday, August 16, 2016 10:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE receive order broken this morning?

On 8/15/2016 3:17 PM, Jousma, David wrote:
> Kurt,   thanks for the response.  I had closed my ticket before they could 
> respond because I compared my secure FTP settings with IBM recommended here: 
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.gim3000/gim3116.htm
>
> SECURE_FTPALLOWED
> SECURE_MECHANISM  TLS
> TLSRFCLEVEL   CCCNONOTIFY
> TLSMECHANISM  FTP
> SECURE_DATACONN   PRIVATE
> KEYRING   keyringname
> EPSV4 TRUE
>
>
>
> In my jobs I had coded TLSMECHANISM  AT-TLS when the failure occurred.  I 
> changed it to TLSMECHANISM  FTP base on the doc above and things started 
> working again, maybe it was a timing co-incidence?   I'll run another job 
> tomorrow when there may be additional maint to download reverting back to 
> AT-TLS.

I suspect it was a coincidence, but please do let us know if that is not the 
case.

Kurt Quackenbush -- IBM, SMP/E Development

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


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: SMPE receive order broken this morning?

[Kurt Quackenbush]

On 8/15/2016 3:17 PM, Jousma, David wrote:

Kurt,   thanks for the response.  I had closed my ticket before they could 
respond because I compared my secure FTP settings with IBM recommended here: 
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.gim3000/gim3116.htm

SECURE_FTPALLOWED
SECURE_MECHANISM  TLS
TLSRFCLEVEL   CCCNONOTIFY
TLSMECHANISM  FTP
SECURE_DATACONN   PRIVATE
KEYRING   keyringname
EPSV4 TRUE



In my jobs I had coded TLSMECHANISM  AT-TLS when the failure occurred.  I 
changed it to TLSMECHANISM  FTP base on the doc above and things started 
working again, maybe it was a timing co-incidence?   I'll run another job 
tomorrow when there may be additional maint to download reverting back to 
AT-TLS.


I suspect it was a coincidence, but please do let us know if that is not 
the case.


Kurt Quackenbush -- IBM, SMP/E Development

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

Re: SMPE receive order broken this morning?

[Jousma, David]

Kurt,   thanks for the response.  I had closed my ticket before they could 
respond because I compared my secure FTP settings with IBM recommended here: 
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.gim3000/gim3116.htm

SECURE_FTPALLOWED 
SECURE_MECHANISM  TLS
TLSRFCLEVEL   CCCNONOTIFY
TLSMECHANISM  FTP
SECURE_DATACONN   PRIVATE
KEYRING   keyringname
EPSV4 TRUE



In my jobs I had coded TLSMECHANISM  AT-TLS when the failure occurred.  I 
changed it to TLSMECHANISM  FTP base on the doc above and things started 
working again, maybe it was a timing co-incidence?   I'll run another job 
tomorrow when there may be additional maint to download reverting back to 
AT-TLS.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kurt Quackenbush
Sent: Monday, August 15, 2016 2:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE receive order broken this morning?

On 8/15/2016 9:40 AM, Jousma, David wrote:
> All,
>
> I apologize if this has been asked, but I've been on vacation for the last 
> week or two.  Last time it worked for me was prior to this.   Seems like 
> something changed?  Seems to be refused at IBM end.   I do have ticket open 
> with them, but thought maybe I might have missed something.
>
>> /bin/ftp -e -v -f "//'SYS1.TCPPARMS(FTPSECUR)'" 
>> deliverycb-bld.dhe.ibm.com
>
> EZY2640I Using 'SYS1.TCPPARMS(FTPSECUR)' for local site configuration 
> parameters .
> EZYFT25I Using //'TCPIP.STANDARD.TCPXLBIN' for FTP translation tables 
> for the co ntrol connection.
> EZYFT31I Using //'TCPIP.STANDARD.TCPXLBIN' for FTP translation tables 
> for the da ta connection.
> EZA1450I IBM FTP CS V2R2
> EZA1772I FTP: EXIT has been set.
> EZYFT18I Using catalog '/usr/lib/nls/msg/C/ftpdmsg.cat' for FTP messages.
> EZA1554I Connecting to: dispby-117.boulder.ibm.com 170.225.15.117 port: 21.
> 220-IBM's internal systems must only be used for conducting IBM's 
> 220-business or for purposes authorized by IBM management.
> 220-
> 220-Use is subject to audit at any time by IBM management.
> 220-
> 220 dhebpcb01 secure FTP server ready.
> EZA1701I >>> AUTH TLS
> 234 SSLv23/TLSv1
> EZA2897I Authentication negotiation failed EZA2898I Unable to 
> successfully negotiate required authentication EZA1735I Std Return 
> Code = 10234, Error Code = 00017 
> _
> Dave Jousma

As already mentioned, IBM did have an upgrade this past weekend for its 
download server infrastructure, and unsecured FTP downloads are no longer 
allowed.  You must use now FTPS or HTTPS when downloading from IBM's servers to 
your z/OS systems.

Unfortunately, perhaps as a result of this deployment, there was also this 
morning an outage with the download infrastructure, but it does appear to be 
working now.  Hopefully Dave received a similar response to his open ticket.

If anyone tries again and continues to have troubles, please open a problem 
record with IBM support.

Kurt Quackenbush -- IBM, SMP/E Development

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


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: SMPE receive order broken this morning?

[Kurt Quackenbush]

On 8/15/2016 9:40 AM, Jousma, David wrote:

All,

I apologize if this has been asked, but I've been on vacation for the last week 
or two.  Last time it worked for me was prior to this.   Seems like something 
changed?  Seems to be refused at IBM end.   I do have ticket open with them, 
but thought maybe I might have missed something.


/bin/ftp -e -v -f "//'SYS1.TCPPARMS(FTPSECUR)'" deliverycb-bld.dhe.ibm.com


EZY2640I Using 'SYS1.TCPPARMS(FTPSECUR)' for local site configuration parameters
.
EZYFT25I Using //'TCPIP.STANDARD.TCPXLBIN' for FTP translation tables for the co
ntrol connection.
EZYFT31I Using //'TCPIP.STANDARD.TCPXLBIN' for FTP translation tables for the da
ta connection.
EZA1450I IBM FTP CS V2R2
EZA1772I FTP: EXIT has been set.
EZYFT18I Using catalog '/usr/lib/nls/msg/C/ftpdmsg.cat' for FTP messages.
EZA1554I Connecting to: dispby-117.boulder.ibm.com 170.225.15.117 port: 21.
220-IBM's internal systems must only be used for conducting IBM's
220-business or for purposes authorized by IBM management.
220-
220-Use is subject to audit at any time by IBM management.
220-
220 dhebpcb01 secure FTP server ready.
EZA1701I >>> AUTH TLS
234 SSLv23/TLSv1
EZA2897I Authentication negotiation failed
EZA2898I Unable to successfully negotiate required authentication
EZA1735I Std Return Code = 10234, Error Code = 00017
_
Dave Jousma


As already mentioned, IBM did have an upgrade this past weekend for its 
download server infrastructure, and unsecured FTP downloads are no 
longer allowed.  You must use now FTPS or HTTPS when downloading from 
IBM's servers to your z/OS systems.


Unfortunately, perhaps as a result of this deployment, there was also 
this morning an outage with the download infrastructure, but it does 
appear to be working now.  Hopefully Dave received a similar response to 
his open ticket.


If anyone tries again and continues to have troubles, please open a 
problem record with IBM support.


Kurt Quackenbush -- IBM, SMP/E Development

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

Re: SMPE receive order broken this morning?

[Tracy Adams]

Yeah, appears to be a problem on the ibm side... the same job that ran Friday 
and got a space error today returns "SSL Required" :-(

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Monday, August 15, 2016 10:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE receive order broken this morning?

I found that I had to change thisoption.  Was specifying AT-TLS prior to this.  
I found this info here: 
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.gim3000/gim3116.htm

TLSMECHANISM  FTP   ; AT-TLS will implement TLS
 ; security.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Donald J.
Sent: Monday, August 15, 2016 10:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE receive order broken this morning?

It appears their ftp server is only accepting TLS1.0 at the moment.
All other options fail.

== Info: TLSv1.1, TLS handshake, Client hello (1):  
=> Send SSL data, 512 bytes (0x200) 
 == Info: error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported 
protocol
 == Info: Closing connection 0

The http server port 443 accepts 1.0/1.1/1.2.   


--
  Donald J.
  dona...@4email.net

On Mon, Aug 15, 2016, at 07:01 AM, Richards, Robert B. wrote:
> Dave,
> 
> It is not just you. I sent a note at 6:48am entitled " PTF order fulfillment 
> issues and getting HOLDDATA". 
> 
> I have not opened a SR yet, so if you get a quick reply, please post what 
> they say. 
> 
> In my case, a FTP GET for full HOLDDATA also failed.
> 
> Bob
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Jousma, David
> Sent: Monday, August 15, 2016 9:40 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SMPE receive order broken this morning?
> 
> All,
> 
> I apologize if this has been asked, but I've been on vacation for the last 
> week or two.  Last time it worked for me was prior to this.   Seems like 
> something changed?  Seems to be refused at IBM end.   I do have ticket open 
> with them, but thought maybe I might have missed something.
> 
> > /bin/ftp -e -v -f "//'SYS1.TCPPARMS(FTPSECUR)'" 
> > deliverycb-bld.dhe.ibm.com
> 
> EZY2640I Using 'SYS1.TCPPARMS(FTPSECUR)' for local site configuration 
> parameters .
> EZYFT25I Using //'TCPIP.STANDARD.TCPXLBIN' for FTP translation tables for the 
> co ntrol connection.
> EZYFT31I Using //'TCPIP.STANDARD.TCPXLBIN' for FTP translation tables for the 
> da ta connection.
> EZA1450I IBM FTP CS V2R2
> EZA1772I FTP: EXIT has been set.
> EZYFT18I Using catalog '/usr/lib/nls/msg/C/ftpdmsg.cat' for FTP messages.
> EZA1554I Connecting to: dispby-117.boulder.ibm.com 170.225.15.117 port: 21.
> 220-IBM's internal systems must only be used for conducting IBM's 
> 220-business or for purposes authorized by IBM management.
> 220-
> 220-Use is subject to audit at any time by IBM management.
> 220-
> 220 dhebpcb01 secure FTP server ready.
> EZA1701I >>> AUTH TLS
> 234 SSLv23/TLSv1
> EZA2897I Authentication negotiation failed EZA2898I Unable to 
> successfully negotiate required authentication EZA1735I Std Return 
> Code = 10234, Error Code = 00017
> 
> _
> Dave Jousma
> Manager Mainframe Engineering, Assistant Vice President 
> david.jou...@53.com
> 1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f
> 616.653.2717
> 
> This e-mail transmission contains information that is confidential and may be 
> privileged.
> It is intended only for the addressee(s) named above. If you receive this 
> e-mail in error, please do not read, copy or disseminate it in any manner.  
> If you are not the intended recipient, any disclosure, copying, distribution 
> or use of the contents of this information is prohibited. Please reply to the 
> message immediately by informing the sender that the message was misdirected. 
> After replying, please erase it from your computer system. Your assistance in 
> correcting this error is appreciated.
> 
> 
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

Re: SMPE receive order broken this morning?

[Jousma, David]

I found that I had to change thisoption.  Was specifying AT-TLS prior to this.  
I found this info here: 
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.gim3000/gim3116.htm

TLSMECHANISM  FTP   ; AT-TLS will implement TLS
 ; security.

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Donald J.
Sent: Monday, August 15, 2016 10:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE receive order broken this morning?

It appears their ftp server is only accepting TLS1.0 at the moment.
All other options fail.

== Info: TLSv1.1, TLS handshake, Client hello (1):  
=> Send SSL data, 512 bytes (0x200) 
 == Info: error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported 
protocol
 == Info: Closing connection 0

The http server port 443 accepts 1.0/1.1/1.2.   


--
  Donald J.
  dona...@4email.net

On Mon, Aug 15, 2016, at 07:01 AM, Richards, Robert B. wrote:
> Dave,
> 
> It is not just you. I sent a note at 6:48am entitled " PTF order fulfillment 
> issues and getting HOLDDATA". 
> 
> I have not opened a SR yet, so if you get a quick reply, please post what 
> they say. 
> 
> In my case, a FTP GET for full HOLDDATA also failed.
> 
> Bob
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Jousma, David
> Sent: Monday, August 15, 2016 9:40 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SMPE receive order broken this morning?
> 
> All,
> 
> I apologize if this has been asked, but I've been on vacation for the last 
> week or two.  Last time it worked for me was prior to this.   Seems like 
> something changed?  Seems to be refused at IBM end.   I do have ticket open 
> with them, but thought maybe I might have missed something.
> 
> > /bin/ftp -e -v -f "//'SYS1.TCPPARMS(FTPSECUR)'" 
> > deliverycb-bld.dhe.ibm.com
> 
> EZY2640I Using 'SYS1.TCPPARMS(FTPSECUR)' for local site configuration 
> parameters .
> EZYFT25I Using //'TCPIP.STANDARD.TCPXLBIN' for FTP translation tables for the 
> co ntrol connection.
> EZYFT31I Using //'TCPIP.STANDARD.TCPXLBIN' for FTP translation tables for the 
> da ta connection.
> EZA1450I IBM FTP CS V2R2
> EZA1772I FTP: EXIT has been set.
> EZYFT18I Using catalog '/usr/lib/nls/msg/C/ftpdmsg.cat' for FTP messages.
> EZA1554I Connecting to: dispby-117.boulder.ibm.com 170.225.15.117 port: 21.
> 220-IBM's internal systems must only be used for conducting IBM's 
> 220-business or for purposes authorized by IBM management.
> 220-
> 220-Use is subject to audit at any time by IBM management.
> 220-
> 220 dhebpcb01 secure FTP server ready.
> EZA1701I >>> AUTH TLS
> 234 SSLv23/TLSv1
> EZA2897I Authentication negotiation failed EZA2898I Unable to 
> successfully negotiate required authentication EZA1735I Std Return 
> Code = 10234, Error Code = 00017
> 
> _
> Dave Jousma
> Manager Mainframe Engineering, Assistant Vice President 
> david.jou...@53.com
> 1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 
> 616.653.2717
> 
> This e-mail transmission contains information that is confidential and may be 
> privileged.
> It is intended only for the addressee(s) named above. If you receive this 
> e-mail in error, please do not read, copy or disseminate it in any manner.  
> If you are not the intended recipient, any disclosure, copying, distribution 
> or use of the contents of this information is prohibited. Please reply to the 
> message immediately by informing the sender that the message was misdirected. 
> After replying, please erase it from your computer system. Your assistance in 
> correcting this error is appreciated.
> 
> 
> 
> 
> --
> 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

--
http://www.fastmail.com - Send your email first class

--
For IBM-MAIN subscribe / signoff / archi

Re: SMPE receive order broken this morning?

[Donald J.]

It appears their ftp server is only accepting TLS1.0 at the moment.
All other options fail.

== Info: TLSv1.1, TLS handshake, Client hello (1):  
=> Send SSL data, 512 bytes (0x200) 
 == Info: error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported 
protocol
 == Info: Closing connection 0

The http server port 443 accepts 1.0/1.1/1.2.   


-- 
  Donald J.
  dona...@4email.net

On Mon, Aug 15, 2016, at 07:01 AM, Richards, Robert B. wrote:
> Dave,
> 
> It is not just you. I sent a note at 6:48am entitled " PTF order fulfillment 
> issues and getting HOLDDATA". 
> 
> I have not opened a SR yet, so if you get a quick reply, please post what 
> they say. 
> 
> In my case, a FTP GET for full HOLDDATA also failed.
> 
> Bob
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Jousma, David
> Sent: Monday, August 15, 2016 9:40 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: SMPE receive order broken this morning?
> 
> All,
> 
> I apologize if this has been asked, but I've been on vacation for the last 
> week or two.  Last time it worked for me was prior to this.   Seems like 
> something changed?  Seems to be refused at IBM end.   I do have ticket open 
> with them, but thought maybe I might have missed something.
> 
> > /bin/ftp -e -v -f "//'SYS1.TCPPARMS(FTPSECUR)'" 
> > deliverycb-bld.dhe.ibm.com
> 
> EZY2640I Using 'SYS1.TCPPARMS(FTPSECUR)' for local site configuration 
> parameters .
> EZYFT25I Using //'TCPIP.STANDARD.TCPXLBIN' for FTP translation tables for the 
> co ntrol connection.
> EZYFT31I Using //'TCPIP.STANDARD.TCPXLBIN' for FTP translation tables for the 
> da ta connection.
> EZA1450I IBM FTP CS V2R2
> EZA1772I FTP: EXIT has been set.
> EZYFT18I Using catalog '/usr/lib/nls/msg/C/ftpdmsg.cat' for FTP messages.
> EZA1554I Connecting to: dispby-117.boulder.ibm.com 170.225.15.117 port: 21.
> 220-IBM's internal systems must only be used for conducting IBM's 
> 220-business or for purposes authorized by IBM management.
> 220-
> 220-Use is subject to audit at any time by IBM management.
> 220-
> 220 dhebpcb01 secure FTP server ready.
> EZA1701I >>> AUTH TLS
> 234 SSLv23/TLSv1
> EZA2897I Authentication negotiation failed EZA2898I Unable to successfully 
> negotiate required authentication EZA1735I Std Return Code = 10234, Error 
> Code = 00017
> 
> _
> Dave Jousma
> Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
> 1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 
> 616.653.2717
> 
> This e-mail transmission contains information that is confidential and may be 
> privileged.
> It is intended only for the addressee(s) named above. If you receive this 
> e-mail in error, please do not read, copy or disseminate it in any manner.  
> If you are not the intended recipient, any disclosure, copying, distribution 
> or use of the contents of this information is prohibited. Please reply to the 
> message immediately by informing the sender that the message was misdirected. 
> After replying, please erase it from your computer system. Your assistance in 
> correcting this error is appreciated.
> 
> 
> 
> 
> --
> 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

-- 
http://www.fastmail.com - Send your email first class

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

Re: SMPE receive order broken this morning?

[Richards, Robert B.]

Dave,

It is not just you. I sent a note at 6:48am entitled " PTF order fulfillment 
issues and getting HOLDDATA". 

I have not opened a SR yet, so if you get a quick reply, please post what they 
say. 

In my case, a FTP GET for full HOLDDATA also failed.

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Monday, August 15, 2016 9:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMPE receive order broken this morning?

All,

I apologize if this has been asked, but I've been on vacation for the last week 
or two.  Last time it worked for me was prior to this.   Seems like something 
changed?  Seems to be refused at IBM end.   I do have ticket open with them, 
but thought maybe I might have missed something.

> /bin/ftp -e -v -f "//'SYS1.TCPPARMS(FTPSECUR)'" 
> deliverycb-bld.dhe.ibm.com

EZY2640I Using 'SYS1.TCPPARMS(FTPSECUR)' for local site configuration 
parameters .
EZYFT25I Using //'TCPIP.STANDARD.TCPXLBIN' for FTP translation tables for the 
co ntrol connection.
EZYFT31I Using //'TCPIP.STANDARD.TCPXLBIN' for FTP translation tables for the 
da ta connection.
EZA1450I IBM FTP CS V2R2
EZA1772I FTP: EXIT has been set.
EZYFT18I Using catalog '/usr/lib/nls/msg/C/ftpdmsg.cat' for FTP messages.
EZA1554I Connecting to: dispby-117.boulder.ibm.com 170.225.15.117 port: 21.
220-IBM's internal systems must only be used for conducting IBM's 220-business 
or for purposes authorized by IBM management.
220-
220-Use is subject to audit at any time by IBM management.
220-
220 dhebpcb01 secure FTP server ready.
EZA1701I >>> AUTH TLS
234 SSLv23/TLSv1
EZA2897I Authentication negotiation failed EZA2898I Unable to successfully 
negotiate required authentication EZA1735I Std Return Code = 10234, Error Code 
= 00017

_
Dave Jousma
Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717

This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error, please do not read, copy or disseminate it in any manner.  If 
you are not the intended recipient, any disclosure, copying, distribution or 
use of the contents of this information is prohibited. Please reply to the 
message immediately by informing the sender that the message was misdirected. 
After replying, please erase it from your computer system. Your assistance in 
correcting this error is appreciated.




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