|
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 anIBM
I API to submit a job. I have an answer for that.Card
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
processor to consume the web service. This program also establishes itssatisfactorily.
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
this
But, if the Card processor does not respond within a timeout value, it
throws an exception. The caller to the web service consumer, monitors
exception and then when it wants to report this result to SystemA, itfinds
that the original TLS/SSL connection that was established with SystemAThe
before, has ended, and it has nothing else to do that to end the job.
server-side job goes down and then the client goes down too.list
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
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 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.