Re: Sample JCL VVDS - replace catalog
you need to either use AMASPZAP or full screen zap. I don't think there are any other kinds of JCL to do it, except maybe for some Vendor programs -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Sample JCL VVDS - replace catalog
Hello Could someone please help me with a sample JCL to reset the VVDS or replace the catalog value in it. Regards Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Help with switching an IP:PORT to TLS V1.2
Lennie Dymoke-Bradshaw wrote:
>Maybe I am trying to teach my granny to suck eggs, but I think TLS includes
the capability to fall back as far as SSLv3 if the other party does not
support TLS. Could this be what you are seeing?
Ah, you're being much too logical. The short answer to your query is "No"
and/or "Not necessarily".
The way SSL/TLS connection setup typically works is that the client says
"Here are the ciphers AND PROTOCOLS" I'm willing to let you, Mr. SSL/TLS
stack, use". Of course the stack can let that default, but the ones I've
seen (like IBM System SSL) don't. This surprised me when I learned it,
because I would have though you could say "Use TLSv1 *or later*" and be done
with it, but no-we have to update our product each time a new TLS version
comes out, simply to tell System SSL "Yes, it's OK to use that protocol".
The result is that you can have a reasonably "modern" client and a
reasonably "modern" server that won't connect, because they don't have any
ciphers in common. It also means that no, things won't necessarily fall
back. Public web servers tend to support fallback-google.com will still do
SSLv3 if you force it to-but more tightly controlled client-server pairs
often do not.
And then there are a whole 'nother set of things that can be incompatible,
like servers that require SNI, and load balancers (I'm looking at you, F5)
that have options ("Unclean shutdown") that irritate System SSL. I suspect
that System SSL is more sensitive to these things than, say, OpenSSL for a
pair of reasons: first, because IBM probably implemented it following the
RFCs; and second, because System SSL has had less real-world exposure to
find out where the real world doesn't follow those.
I'm reminded of the mid-90s when I was apparently the only one on the planet
running a primary DNS using SQL/DS on VM/ESA. IBM implemented TTL per the
RFC, so TTL=0 meant no caching; apparently the rest of the world takes TTL=0
to mean "cache indefinitely". It's fuzzy at this distance but I think IBM
had to change their implementation. (And it's possible I'm describing the
problem wrong, again, 'cause it was a thousand years ago-I just remember
that we had a big problem until IBM fixed it to NOT follow the letter of the
RFC.)
The ubiquity of OpenSSL means it Just Works, so non-Z folks are sorta
spoiled here (in a good way-"Machines should work, people should think" and
all that).
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Help with switching an IP:PORT to TLS V1.2
Maybe I am trying to teach my granny to suck eggs, but I think TLS includes the capability to fall back as far as SSLv3 if the other party does not support TLS. Could this be what you are seeing? Lennie Dymoke-Bradshaw https://rsclweb.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Don Poitras Sent: 25 December 2021 03:15 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Help with switching an IP:PORT to TLS V1.2 AT-TLS is mutually exclusive with applications that actually call SSL functions (OpenSSL, GSK, etc.). The "AT" part means "Application Transparent". i.e, the program just uses sockets and doesn't deal with encryption at all. There's no way to set TLS 1.2 until one answers the question as to what's actually being used. On Fri, 24 Dec 2021 03:24:51 +, kekronbekron wrote: >Plus, I remember there's some environment variables that must be set for >things like this. >At least that's what I've seen in LDAPS, for example. >GSK_SSL_something type variables to tune, turn off, or allow only specific >SSL/TLS versions, or ciphers. > >- KB > >‐‐‐ Original Message ‐‐‐ > >On Thursday, December 23rd, 2021 at 10:52 PM, Matthew Stitt > wrote: > >> Are you sure the SSL options are turned off, leaving only the TLSV12 option >> on? >> >> Matthew >> >> On Thu, 23 Dec 2021 10:01:26 -0700, Lizette Koehler stars...@mindspring.com >> wrote: >> >> > We have done the Packet trace. It was not conclusive. >> > >> > Only showed that TLS V1.2 is being used. However - some were thinking that >> > was not true since the connection (according to them) was behaving like >> > SSLV3 what ever that means. >> > >> > Lizette >> > >> > -Original Message- >> > >> > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On >> > Behalf Of Don Poitras >> > >> > Sent: Thursday, December 23, 2021 8:06 AM >> > >> > To: IBM-MAIN@LISTSERV.UA.EDU >> > >> > Subject: Re: Help with switching an IP:PORT to TLS V1.2 >> > >> > You could also just do a packet trace. Send the output to Wireshark. It >> > can format all the TLS hand-shaking traffic. The question I'd have, given >> > the original description is whether AT-TLS is being used at all. Perhaps >> > the program is using OpenSSL or GSK? >> > >> > https://www.ibm.com/support/pages/how-capture-and-format-ssl-compon >> > ent-trace -- 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
