Re: TLS/SSL issue -- MIDRANGE-L

Ok...

So the gsk *SRVPGM uses ACTGRP(*CALLER),
what activation group does your program run in?
How about the card processor?

It's possible the GSK code is doing some unexpected cleanup I suppose, but
you'd have to ask IBM.

You might try making sure your program and the card processor are running
in different ACTGRPs.

If the card processor is using *CALLER, just create an ILE CL wrapper for
the call the uses a named ACTGRP.

HTH,
Charles

On Thu, Mar 10, 2022 at 2:07 PM Javier Sanchez <
javiersanchezbarquero@xxxxxxxxx> wrote:

Charles,

Yes. the server-side app is ILE, and the card processor consumer is also
ILE. Effectively, I am monitoring the call to the web service consumer.
within a MONITOR body In fact, when I debug my program (the caller to the
WS consumer) I can see the jump to the ON-ERROR body of the monitor. When
I get out of this part, I try then to send a message back to my peer
client, I invoke the gsk_secure_soc_write() API either if I received a
successful or unsuccessful attempt, and then I get GSKit error 503 which
means: SSL session has been previously ended.

But this happens while I call the WS consumer AND this consumer detects a
timeout AND it throws an exception. If the WS consumer is successful, the
monitor flows normal after the ENDMON opcode and I am able to return the
message back to the client.

So, something is messing up my SSL environment just because the WS consumer
threw a monitored exception when it detected a timeout. Luckily these
timeout events happen the least, not the most, and that lets us manage the
restoration of that job. But this is not right and I have to get a
solution to this.

Any more comments, gents?

Thanks Charles.

El jue, 10 mar 2022 a las 14:19, Charles Wilt (<charles.wilt@xxxxxxxxx>)
escribió:

2) No. gsk_environment_open() would return different handles. Note that
your app would need to keep them separated. Sounds like that's being done
as it wouldn't work right at all if not.
3) Because your app isn't handling the error. If not handled, an
exception gets percolated upwards to be handled. Your app loses control.
4) Possibly an added consideration, but only because of #3.

You haven't mentioned if your server app is ILE or not, nor if the card
process app is ILE or OPM.

If your app is ILE, I'd suggest having a MONITOR/ON-ERROR block around

the

call to the processor.
You may need/want to look at what is being sent back, and decide if you
need a ON-ERROR xxxxx type block.

I'd suggest reading through "Handling Exceptions"
https://www.ibm.com/docs/en/i/7.4?topic=handling-exceptions

And be sure to look at indicated references

Additionally, to learn how ILE exception handling works, read:

- Exception Handling Overview
<https://www.ibm.com/docs/en/ssw_ibm_i_74/rzasc/hxovr.htm#hxovr>

(for

general concepts)

- Using RPG-Specific Handlers
<https://www.ibm.com/docs/en/ssw_ibm_i_74/rzasc/hxrpg.htm#hxrpg>

- The sections on error handling in ILE Concepts.

Charles

On Thu, Mar 10, 2022 at 10:16 AM Javier Sanchez <
javiersanchezbarquero@xxxxxxxxx> wrote:

Just recently I was asking about the use of the SBMJOB equivalent of an

IBM

I API to submit a job. I have an answer for that.

Let me tell you what my problem is right now.

I've got two IBM i partitions, say SystemA and SystemB. I establish a
TLS/SSL communications connection between them. Then I can exchange
arbitrary and totally customized messages that only the two endpoints
understand.

SystemA is the client and SystemB is the server. SystemA sends a

message

to SystemB with some sensitive PCI-DSS compliant information in order

to,

in turn, connect to a third party web service provider outside the
organization. Let's call the latter the Card Processor.

This is done by SystemB calling (literally with a CALL operation) the

Card

processor to consume the web service. This program also establishes

its

own TLS/SSL connection with the card processor.

It happens that, if the connection with the Card processor is

successful,

when it gives control back to its caller, everything works

satisfactorily.

But, if the Card processor does not respond within a timeout value, it
throws an exception. The caller to the web service consumer, monitors

this

exception and then when it wants to report this result to SystemA, it

finds

that the original TLS/SSL connection that was established with SystemA
before, has ended, and it has nothing else to do that to end the job.

The

server-side job goes down and then the client goes down too.

This behavior has been observed only if, and only if, the third-party

web

service consumer throws an exception to report the timeout. Otherwise

it

returns normal and nothing bad happens.

So I would ask these items:

1. On the server side, when I first call gsk_environment_open(), I get

a

handle for that.
2. If the third-party (on the same job) calls gsk_environment_open()

too,

would it get the same handle as the first one? I mean like if it

shares

the same handle?

3. Why would an exception thrown from the third-party web consumer
close/end my original TLS/SSL environment?

4. Would it have to do with Activation Group related stuff?

Well, this is my issue. I have not been able to find out the cause of

it.

Will appreciate your comments, tips, recommendations, etc.

Javier.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription

related

questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com