info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
ShopzSeries SSL Connectivity Test
1,112 views
Skip to first unread message
John Chase
Sep 13, 2012, 9:03:14 AM9/13/12
to
Hi, All,
Anybody successfully using SSL/TLS to download stuff from ShopzSeries direct to z/OS? How does one need to set up the z/OS client to do so?
Trying the ShopzSeries Connectivity Test for the first time. I've set up the FTP.DATA specifications according to the sample provided by ShopzSeries, and am using their sample JCL almost unchanged (using local JOB card is about the only change). All I get so far is this:
EZA1450I IBM FTP CS V1R13
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
EZA1534I *** Control connection with dispby-117.boulder.ibm.com dies.
EZA1457I You must first issue the 'OPEN' command
EZA1735I Std Return Code = 10234, Error Code = 00010
I'm using our SMP/E Client Certificate that we use for RECEIVE ORDER jobs. The return code and client error code say nothing more than "connection failed"; no clues as to why.
Might we need to "poke a hole" in our firewall? Haven't tried that yet; RECEIVE ORDER jobs work without it anyway.
Any other ideas would be appreciated as well.
TIA,
-jc-
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
Anybody successfully using SSL/TLS to download stuff from ShopzSeries direct to z/OS? How does one need to set up the z/OS client to do so?
Trying the ShopzSeries Connectivity Test for the first time. I've set up the FTP.DATA specifications according to the sample provided by ShopzSeries, and am using their sample JCL almost unchanged (using local JOB card is about the only change). All I get so far is this:
EZA1450I IBM FTP CS V1R13
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
EZA1534I *** Control connection with dispby-117.boulder.ibm.com dies.
EZA1457I You must first issue the 'OPEN' command
EZA1735I Std Return Code = 10234, Error Code = 00010
I'm using our SMP/E Client Certificate that we use for RECEIVE ORDER jobs. The return code and client error code say nothing more than "connection failed"; no clues as to why.
Might we need to "poke a hole" in our firewall? Haven't tried that yet; RECEIVE ORDER jobs work without it anyway.
Any other ideas would be appreciated as well.
TIA,
-jc-
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
Sep 13, 2012, 9:45:08 AM9/13/12
to
Turn on some FTP tracing. You can do it in FTP.DATA. Take a look at the TRACE (?) statement in the CS configuration manuals and pick some plausible options.
Charles
Charles
Tom Ambros
Sep 13, 2012, 10:17:47 AM9/13/12
to
We are in the process of implementing the Payment Card Industry Data
Security Standards and in an effort to cover everything and not be obliged
to look at each instance in a one-off we are curious how other sysplex
implementations were done. We would like to understand if we can approach
this as virtually a single system image with the appropriate obfuscation,
data and network access controls or if it gets more complicated than that.
We're running a single zOS sysplex that hosts all our workload and we'd
like to keep it that way. We've read the PCI-DSS standard documentation
and were impressed by how much they leave open to interpretation and we
have read the atsec doc on large system implementations.
What has been the experience of the people here? Thank you for your
help, maybe we can offer an idea or two of our own that might be useful.
Thomas Ambros
Operating Systems and Connectivity Engineering
518-436-6433
This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose such information for any purpose other than to provide the services for which you are receiving the information.
127 Public Square, Cleveland, OH 44114
If you prefer not to receive future e-mail offers for products or services from Key
send an e-mail to mailto:DNERe...@key.com with 'No Promotional E-mails' in the
SUBJECT line.
Security Standards and in an effort to cover everything and not be obliged
to look at each instance in a one-off we are curious how other sysplex
implementations were done. We would like to understand if we can approach
this as virtually a single system image with the appropriate obfuscation,
data and network access controls or if it gets more complicated than that.
We're running a single zOS sysplex that hosts all our workload and we'd
like to keep it that way. We've read the PCI-DSS standard documentation
and were impressed by how much they leave open to interpretation and we
have read the atsec doc on large system implementations.
What has been the experience of the people here? Thank you for your
help, maybe we can offer an idea or two of our own that might be useful.
Thomas Ambros
Operating Systems and Connectivity Engineering
518-436-6433
This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose such information for any purpose other than to provide the services for which you are receiving the information.
127 Public Square, Cleveland, OH 44114
If you prefer not to receive future e-mail offers for products or services from Key
send an e-mail to mailto:DNERe...@key.com with 'No Promotional E-mails' in the
SUBJECT line.
Staller, Allan
Sep 13, 2012, 10:26:59 AM9/13/12
to
As I recall, there is a "shadow sysplex" within the main sysplex that keeps the PCI data separate from "general data".
See if you can find a copy of "PCI COMPLIANCE with z/OS Communcations Server and System z" from Gwen Dente at IBM. It will answer many of your questions....
If you can't find it , contact Gwen (gdente at us.ibm.com)
HTH,
<snip>
See if you can find a copy of "PCI COMPLIANCE with z/OS Communcations Server and System z" from Gwen Dente at IBM. It will answer many of your questions....
If you can't find it , contact Gwen (gdente at us.ibm.com)
HTH,
<snip>
We are in the process of implementing the Payment Card Industry Data Security Standards and in an effort to cover everything and not be obliged to look at each instance in a one-off we are curious how other sysplex implementations were done. We would like to understand if we can approach this as virtually a single system image with the appropriate obfuscation, data and network access controls or if it gets more complicated than that.
We're running a single zOS sysplex that hosts all our workload and we'd like to keep it that way. We've read the PCI-DSS standard documentation and were impressed by how much they leave open to interpretation and we have read the atsec doc on large system implementations.
</snip>
We're running a single zOS sysplex that hosts all our workload and we'd like to keep it that way. We've read the PCI-DSS standard documentation and were impressed by how much they leave open to interpretation and we have read the atsec doc on large system implementations.
Charles Mills
Sep 13, 2012, 10:34:50 AM9/13/12
to
I did a (vendor) presentation at SHARE Atlanta on PCI DSS. If anyone is
interested you can probably find it by searching PCI on the SHARE Atlanta
Web site. If not, send me a private note and I will send you the PPT.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On
interested you can probably find it by searching PCI on the SHARE Atlanta
Web site. If not, send me a private note and I will send you the PPT.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On
Behalf Of Tom Ambros
Sent: Thursday, September 13, 2012 7:12 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: PCI-DSS, sysplex implementation question.
We are in the process of implementing the Payment Card Industry Data
Security Standards and in an effort to cover everything and not be obliged
to look at each instance in a one-off we are curious how other sysplex
implementations were done. We would like to understand if we can approach
this as virtually a single system image with the appropriate obfuscation,
data and network access controls or if it gets more complicated than that.
We're running a single zOS sysplex that hosts all our workload and we'd
like to keep it that way. We've read the PCI-DSS standard documentation
and were impressed by how much they leave open to interpretation and we
have read the atsec doc on large system implementations.
What has been the experience of the people here? Thank you for your
help, maybe we can offer an idea or two of our own that might be useful.
Sent: Thursday, September 13, 2012 7:12 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: PCI-DSS, sysplex implementation question.
We are in the process of implementing the Payment Card Industry Data
Security Standards and in an effort to cover everything and not be obliged
to look at each instance in a one-off we are curious how other sysplex
implementations were done. We would like to understand if we can approach
this as virtually a single system image with the appropriate obfuscation,
data and network access controls or if it gets more complicated than that.
We're running a single zOS sysplex that hosts all our workload and we'd
like to keep it that way. We've read the PCI-DSS standard documentation
and were impressed by how much they leave open to interpretation and we
have read the atsec doc on large system implementations.
What has been the experience of the people here? Thank you for your
help, maybe we can offer an idea or two of our own that might be useful.
Juan Mautalen
Sep 13, 2012, 12:46:14 PM9/13/12
to
Hi:
We have 2 Lpars in sysplex (z/OS 1.11), say LparA and LparB. Consoles are configured with LOGON(OPTIONAL) on both systems. Each system has its own RACF database.
If an operator is already logoned to an LparA console and tries to logon to an LparB console, then logon fails with the following message:
CNZ0005I LOGON REJECTED. REASON=USERID ABC123 IN USE ON SYSTEM SYSA
CONSOLE MSTRSYSA
Is this normal behaviour?
Is there any configuration change that can be made to allow the same operator to logon to consoles on both systems at the same time?
Thanks in advance for your help,
JUAN MAUTALEN
We have 2 Lpars in sysplex (z/OS 1.11), say LparA and LparB. Consoles are configured with LOGON(OPTIONAL) on both systems. Each system has its own RACF database.
If an operator is already logoned to an LparA console and tries to logon to an LparB console, then logon fails with the following message:
CNZ0005I LOGON REJECTED. REASON=USERID ABC123 IN USE ON SYSTEM SYSA
CONSOLE MSTRSYSA
Is this normal behaviour?
Is there any configuration change that can be made to allow the same operator to logon to consoles on both systems at the same time?
Thanks in advance for your help,
JUAN MAUTALEN
R.S.
Sep 13, 2012, 1:19:47 PM9/13/12
to
W dniu 2012-09-13 18:46, Juan Mautalen pisze:
is whole sysplex.
I don't know any method to change it.
BTW: in theory there is no need to logon on both consoles the operator
can work (issue commands) on both system from single console.
--
Radoslaw Skorupka
Lodz, Poland
--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.
This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.
BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: in...@brebank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88.
Według stanu na dzień 01.01.2012 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.410.984 złotych.
> Hi:
>
> We have 2 Lpars in sysplex (z/OS 1.11), say LparA and LparB. Consoles
> are configured with LOGON(OPTIONAL) on both systems. Each system has
> its own RACF database.
>
> If an operator is already logoned to an LparA console and tries to
> logon to an LparB console, then logon fails with the following
> message:
>
> CNZ0005I LOGON REJECTED. REASON=USERID ABC123 IN USE ON SYSTEM SYSA
> CONSOLE MSTRSYSA
>
> Is this normal behaviour? Is there any configuration change that can
> be made to allow the same operator to logon to consoles on both
> systems at the same time?
It is normal behavior. You can logon on console only once and the scope
>
> We have 2 Lpars in sysplex (z/OS 1.11), say LparA and LparB. Consoles
> are configured with LOGON(OPTIONAL) on both systems. Each system has
> its own RACF database.
>
> If an operator is already logoned to an LparA console and tries to
> logon to an LparB console, then logon fails with the following
> message:
>
> CNZ0005I LOGON REJECTED. REASON=USERID ABC123 IN USE ON SYSTEM SYSA
> CONSOLE MSTRSYSA
>
> Is this normal behaviour? Is there any configuration change that can
> be made to allow the same operator to logon to consoles on both
> systems at the same time?
is whole sysplex.
I don't know any method to change it.
BTW: in theory there is no need to logon on both consoles the operator
can work (issue commands) on both system from single console.
--
Radoslaw Skorupka
Lodz, Poland
--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.
This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.
BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: in...@brebank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88.
Według stanu na dzień 01.01.2012 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.410.984 złotych.
McKown, John
Sep 13, 2012, 1:41:21 PM9/13/12
to
I did a command that I have which lists ENQ information. I found an entry like:
Qname=SYSZCNZ
Rname=USERID#????????|consname|
Jobname=CONSOLE (which was the name of the z/OS SMCS console the user was logged on to)
Type=EXCL (Exclusive)
Status=OWNED
Scope=SYSPLEX
Where the ??????? is 8 character RACF id (padded with blanks if necessary) and the "consname" is the name of the console.
This certainly looks like it could be the ENQ done by console support. You could change the scope from SYSPLEX to SYSTEM via the GRS RNL, or even to STEP to allow the same user onto multiple consoles on a single system image. However, I wonder if this is wise. I don't know why the scope is SYSPLEX and not SYSTEM or even why it is issued. It may be that the USERID logged on my be used in other parts of the system and is assumed to be unique within the SYSPLEX. If so, who knows what would happen if you change this ENQ?
from SG247605, section 27.1.1
<quote>
The new console data structures no longer require sysplex-wide serialization to make most updates. The system on which a console is active owns the data, and will hold ENQ SYSZCNZ CONNAME#consname. The other systems may not display the newest data.
</quote>
So, there may be data structures in the CONSOLE address space which are dependent on this ENQ be SYSPLEX-wide. Or, perhaps, it is a way for z/OS to "know" which system is actually controlling a specific console. I'm a bit confused by this because, in a SYSPLEX, the console names must be unique. And the ENQ for the USERID#... has the console id in it. So why does console to a "generic" ENQ search, ignoring the console name. In the words of Vinnie Babarino: "I'm so confused!" (John Travolta in "Welcome Back Kotter").
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets®
9151 Boulevard 26 • N. Richland Hills • TX 76010
(817) 255-3225 phone •
john....@healthmarkets.com • www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. –The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
Qname=SYSZCNZ
Rname=USERID#????????|consname|
Jobname=CONSOLE (which was the name of the z/OS SMCS console the user was logged on to)
Type=EXCL (Exclusive)
Status=OWNED
Scope=SYSPLEX
Where the ??????? is 8 character RACF id (padded with blanks if necessary) and the "consname" is the name of the console.
This certainly looks like it could be the ENQ done by console support. You could change the scope from SYSPLEX to SYSTEM via the GRS RNL, or even to STEP to allow the same user onto multiple consoles on a single system image. However, I wonder if this is wise. I don't know why the scope is SYSPLEX and not SYSTEM or even why it is issued. It may be that the USERID logged on my be used in other parts of the system and is assumed to be unique within the SYSPLEX. If so, who knows what would happen if you change this ENQ?
from SG247605, section 27.1.1
<quote>
The new console data structures no longer require sysplex-wide serialization to make most updates. The system on which a console is active owns the data, and will hold ENQ SYSZCNZ CONNAME#consname. The other systems may not display the newest data.
</quote>
So, there may be data structures in the CONSOLE address space which are dependent on this ENQ be SYSPLEX-wide. Or, perhaps, it is a way for z/OS to "know" which system is actually controlling a specific console. I'm a bit confused by this because, in a SYSPLEX, the console names must be unique. And the ENQ for the USERID#... has the console id in it. So why does console to a "generic" ENQ search, ignoring the console name. In the words of Vinnie Babarino: "I'm so confused!" (John Travolta in "Welcome Back Kotter").
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets®
9151 Boulevard 26 • N. Richland Hills • TX 76010
(817) 255-3225 phone •
john....@healthmarkets.com • www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets® is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. –The Chesapeake Life Insurance Company®, Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
McKown, John
Sep 13, 2012, 1:44:16 PM9/13/12
to
Forget the part about STEP level ENQ. All ENQs are done by the CONSOLE address space, and so STEP is not relevant.
John Chase
Sep 13, 2012, 2:04:42 PM9/13/12
to
On Thu, 13 Sep 2012 06:44:53 -0700, Charles Mills <char...@MCN.ORG> wrote:
>Turn on some FTP tracing. You can do it in FTP.DATA. Take a look at the TRACE (?) statement in the CS configuration manuals and pick some plausible options.
>
>Charles
Not much new with TRACE in the FTP.DATA:
>Turn on some FTP tracing. You can do it in FTP.DATA. Take a look at the TRACE (?) statement in the CS configuration manuals and pick some plausible options.
>
>Charles
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
FC0994 authServer: secure_socket_init failed with rc = 420 (Socket closed by rem
234 SSLv23/TLSv1
ote partner)
EZA2897I Authentication negotiation failed
EZA1534I *** Control connection with dispby-117.boulder.ibm.com dies.
Still nothing substantive about "rc = 420" that I can find anywhere. Time to try "poke hole in firewall", I guess.
EZA1534I *** Control connection with dispby-117.boulder.ibm.com dies.
-jc-
Mike Schwab
Sep 13, 2012, 2:33:48 PM9/13/12
to
TRACETCP does route tracing using the port number you specify to find
the IP address that is blocking the connection. Freeware download.
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
the IP address that is blocking the connection. Freeware download.
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
Charles Mills
Sep 14, 2012, 8:08:16 PM9/14/12
to
My bad -- DEBUG, not TRACE.
Try
DEBUG FLO
DEBUG INT
DEBUG ACC
DEBUG SEC
Charles
Try
DEBUG FLO
DEBUG INT
DEBUG ACC
DEBUG SEC
Charles
0 new messages