× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  1.  Home
  2. MIDRANGE-L
  3. March 2022

Re: TLS/SSL issue

Good question.
Answer:
The listener program runs in a named activation group of its own. The
spawned worker program has *CALLER and my other business logic program has
also *CALLER. The latter calls the card processor WS consumer, and it has
the traditional QILE activation group. So I think this makes them run in
different activation groups. In fact that's what I wanted.

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

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

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


As an Amazon Associate we earn from qualifying purchases.

This thread ...
Replies:
Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.