@Tom, did you ever get this resolved? What was the resolution?
Charles
On Tue, 20 Jun 2023 10:18:44 -0500, Tom Longfellow
wrote:
>Thanks to all so far. Still on my journey.
>
>I have confirmed that my Firewall staff has not blocked me. (ports 80 and 443
>found at IBM)
>I have confirmed
SMOE has a Debug parm too.
On Tue, Jun 20, 2023 at 11:22 AM Phil Smith III wrote:
> Tom Longfellow wrote, in part:
>
> >GIM44336S ** AN UNUSUAL CONDITION OCCURRED. GIMJVREQ -
> java.net.SocketException: Write failed
>
>
>
> WRITE failed? That doesn't sound like a cert issue to me. Anyone know
Tom Longfellow wrote, in part:
>GIM44336S ** AN UNUSUAL CONDITION OCCURRED. GIMJVREQ -
>java.net.SocketException: Write failed
WRITE failed? That doesn't sound like a cert issue to me. Anyone know if
gsktrace can be enabled for this? (Doubtful but it would sure help.)
>As ugly as a Java
1. >A new Client Certificate is in place
I know TLS pretty well but I don't know RECEIVE ORDER at all. Client
Certificates are relatively unusual. Does anyone know for sure: does RECEIVE
ORDER require a client certificate? If not, then this is a red herring.
2. > Write failed
That *sounds*
Thanks to all so far. Still on my journey.
I have confirmed that my Firewall staff has not blocked me. (ports 80 and 443
found at IBM)
I have confirmed that my DNS world can find the new host names. And even
confirmed that the old names are working DNS aliases.
My HTTPS references were
On Wed, 14 Jun 2023 09:17:04 -0500, Tom Longfellow
wrote:
>
>My current detective work is trying to discover the IPV4 used today by IBM.
>So I can take my Hat in hand and go explain all of this to the Firewall staff
>so they can slice a microbe of time to search their logs and/or change
Thank you. Thank You.THANK YOU.
It is great to find out I am not alone in this. Maybe we can arrange an
uprising. I will bring some Pitchforks and Torches when we storm the Castle.
Here is where I stand today with this.
There are IBM announcements out there about a server change and
We've been having this same issue since early June, and we went through and
made sure all of the new certs are in place. And our download jobs work
occasionally, and then fail with either write or read failed at other times.
Has anyone gotten this working and what was the resolution? It's
> GIM44336S ** AN UNUSUAL CONDITION OCCURRED. GIMJVREQ -
> java.net.SocketException:
> Write failed
> My gut reaction is the the SocketException is because the Socket is not being
> correctly negotiated for encryption.
That does not smell like a certificate problem to me at
Tom Longfellow wrote, in part:
>Now to be told by an acknowledged expert that the Intermediate Cert is NOT
>needed.
>For now I will just leave it on the ring since I went to all the trouble to
>acquire it.
Strongly recommend that once you get this working, you remove that cert. As I
wrote
thank you
RACDCERT CERTAUTH LISTCHAIN has been both useful and frustrating.
I list the new Intermediate (by label name it was added with). Bottom line is
that it says the chain is completed back the the DigiCert Global G2 root .
Still does not work though
=-=-=-=-=-=-
Kurt
the SMP message is
GIM44336S ** AN UNUSUAL CONDITION OCCURRED. GIMJVREQ -
java.net.SocketException:
Write failed
GIM20501IRECEIVE PROCESSING IS COMPLETE. THE HIGHEST RETURN CODE WAS 12.
My gut
For those with certificate chain problems, have you tried RACDCERT
CHECKCERT as documented here:
https://www.ibm.com/docs/en/zos/2.5.0?topic=certificates-racdcert-checkcert-check-certificate-certificate-chain
and RACDCERT LISTCHAIN as documented here:
You might try
RACDCERT CHECKCERT('') and see what RACF thinks in the certificate. If
there were funny chars, it should show up
Colin
On Tue, 13 Jun 2023 at 14:40, Peter Vander Woude
wrote:
> I open the file created by the export, using notepad. Select all the text
> in the file, copy and
I open the file created by the export, using notepad. Select all the text in
the file, copy and then in an edit of a dataset with the following
characteristics:
recfm=vb
lrecl=84
I paste the text from the pc file. The use that as the source for the
RACDCERT import of the CA Cert, making
> ... The named labels, the download steps (Only the new Intermediate was
> required)., the upload steps, the
> Cert adds (yes trusted). the keyring connect to the same keyring used for
> the last successful loads.
The intermediate is NOT required. You can safely remove that one from your
Hello Tom,
If you have been using COPY/PASTE to move/convert text data up to ISPF EDIT,
you may have some character conversion issue. The one I am seeing here lateky
are in COPY/PASET from MS Teams chat sessions. In my case some blank
characters are ending up a x'41' EBCDIC - RACF would not
On 13/06/2023 8:04 am, Tom Longfellow wrote:
I am beginning to suspect some new evil is afoot in the land of Java --
complete with unhelpful cryptic error messages.
How old is your Java installation, and how old are the certificates
required?
It's possible that e.g. Java hasn't been updated
Charles added:
>I would not generally expect the necessity of installing any intermediates on
>the client side.
I'd phrase it more strongly: you do NOT want intermediates on a client machine,
because when they expire, nobody will notice until things don't work, and won't
think to check them.
I suspect that one you listed first is superfluous but no matter.
Does SMPE really want a client certificate? Where did you get it from? What
signed it?
If SMPE really wants that client certificate then you should make it the
default so SMPE can find it.
Are all of those certs on the ring
Thank you Charles.
you have just spelled out every single step that I have already performed. The
named labels, the download steps (Only the new Intermediate was required)., the
upload steps, the Cert adds (yes trusted). the keyring connect to the same
keyring used for the last successful
>What I cannot find is the name or source of this unnamed thing.
Name: IBM uses certificates with chains ending in two different DigiCert roots
with very similar names. This is a source of confusion.
DigiCert Global Root CA
DigiCert Global Root G2
Someone else posted with servers use which.
> I did finally get the Certificate loaded, defined and attached to my SMPE
> keyring.
> The jobs still fail mysteriously.The only clue being that displaying the
> new key via RACF says that it is 'Incomplete'
I don't know about your RACF "incomplete" issue, but I suggest you double check
IMHO, both curl and get belong in the base.
From: IBM Mainframe Discussion List on behalf of
Paul Gilmartin <042bfe9c879d-dmarc-requ...@listserv.ua.edu>
Sent: Monday, June 12, 2023 9:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: The new requirement
On Mon, 12 Jun 2023 08:22:03 -0500, Peter Vander Woude wrote:
>What I have done, to get these certificates, is to look at the keystore on the
>pc, and save a copy of the certauth record from there, in base64 .cer format.
>Then edit it, copy and past into a dataset on the mainframe.
>
Is it
What I have done, to get these certificates, is to look at the keystore on the
pc, and save a copy of the certauth record from there, in base64 .cer format.
Then edit it, copy and past into a dataset on the mainframe.
Peter
On Mon, 12 Jun 2023 08:13:54 -0500, Paul Gilmartin wrote:
>On Mon,
On Mon, 12 Jun 2023 02:49:14 +, Timothy Sipples wrote:
>...
>When you get "bootstrapped" you'll probably want to install curl for z/OS (or
>something functionally similar) to make this process easier.
>
"Bootstrap" is a critical term here. It reflects the antinomy in how can I
elevate
Here's the only cert I added for the RECEIVE ORDER process to continue
working. Be sure serial number matches yours.
Digital certificate information for CERTAUTH:
Label: DigiCert Global G2 Root
Start Date: 2013/08/01 07:00:00
End Date: 2038/01/15 07:00:00
Serial Number:
As a follow up, curl is available from Rocket Software. There's also a build of
curl available here:
https://github.com/ZOSOpenTools
And there's a port of wget if you prefer that, but it's more of a work in
progress at this instant.
More information here, and contributors welcome:
On 12/06/2023 2:59 pm, Tom Longfellow wrote:
I am worn out from all of these "learning" opportunities and want to get back to
"doing" the job I am paid to do.
IBM doesn't do its customers any favors with the way they handle
certificates.
Every other operating system installs default
Thanks Charles.
I have come to the same conclusion that I am missing an "appropriate"
certificate.
What I cannot find is the name or source of this unnamed thing. And sometimes
when I find appropriate certs I am presented with barriers to acquiring them.
I am not opposed to adding IT once
I am worn out from all of these "learning" opportunities and want to get back
to "doing" the job I am paid to do.
There should be no need for me to start writing code or installing curl or any
of the other fine suggestions here.
As I see it. IBM changed a reliable working encrypted exchange
Tom Longfellow wrote:
> I tried to find an ftp path to a digicert location because I have pretty free
>access for internet connections that the mainframe initiates.
You should have the z/OS Client Web Enablement Toolkit with its HTTP/HTTPS
protocol enabler and REXX samples. Conceivably you could
I would not generally expect the necessity of installing any intermediates on
the client side.
But yes, trust is an absolute requirement. An untrusted certificate effectively
does not exist.
Charles
On Sun, 11 Jun 2023 12:27:57 -0400, Matt Hogstrom wrote:
>Did you trust the cert when
Did you trust the cert when importing. The default is to leave it untrusted.
Also, is there an intermediate key on the chain you don’t have imported or in
the keyring
I’ve learning certain lately for a project and I say I’m plumbing the depths of
my ignorance which seems bottomless at times
Run a RACDCERT LISTRING on the ring.
Is the appropriate DigiCert root on the ring and trusted?
If not, FTP will fail.
Charles
On Sun, 11 Jun 2023 10:18:10 -0500, Tom Longfellow
wrote:
>The Journey continues:Step by Step - Inch by Inch
>
>Obscurity and (my) Ignorance still trumps
The Journey continues:Step by Step - Inch by Inch
Obscurity and (my) Ignorance still trumps usability.
I did finally get the Certificate loaded, defined and attached to my SMPE
keyring.
The jobs still fail mysteriously.The only clue being that displaying the
new key via RACF says that
I tried to find an ftp path to a digicert location because I have pretty free
access for internet connections that the mainframe initiates.
The barrier for me is that if any windows or browser device is used. The
security policies prevent me from handling the potentially 'toxic' material.
I
On 11/06/2023 12:17 am, Tom Longfellow wrote:
Has anyone managed to accomplish this using the power of the mainframe without
ruffling the feathers of the Windows/Browser world?
I have full certificate management powers under RACF on the mainframe. I just
do not have a usable Certificate to
What communication paths do you have between the Internet at large and your
mainframe?
Can you FTP from outside with your mainframe?
Can you IND$FILE from an Internet-connected desktop to your mainframe? Either
way -- push or pull?
Can you cut-and-paste from an Internet-connected desktop into a
Yes. I saw the warnings for months.
I also saw an online reference that the https java javastore keys are already
good to go.
So, of course, I got burned again with failed SMPE RECEIVE ORDER jobs that use
javastore.
Back to the warnings. And the links to where to get the required
41 matches
Mail list logo
