I agree that the database access story for PASE isn't as clear as it
should be; perhaps no fault of IBM's though. However, this does affect
programmers for both runtimes and runtime consumers - we're still not
sure what's the best method for working with DB2. I think Richard's
comments weren't out of spite, but of concern.
As you say, libdb400/QSQCLI is... flaky, and from working with it, I
definitely agree with what you've been saying for a while about it.
Having Python et al versions to compare with helps, but tripping up on
bugs that kill the QSQCLI service program and the entire PASE process
with it due to an ILE pointer snafu can be quite annoying.
XMLSERVICE I haven't brushed up with, but as you also said, seems to
be unsustainable. Hopefully Liam and perhaps a community around
ILEusion can make it work better for both remote and local cases.
Worst case, there's always writing bespoke microservices per task.
It's good to know this will change for the better in the future.
Unfortunately, we have to work with what we have in the meantime.
Hopefully the community will come together for the stuff that they can
work on themselves. (like ILEusion) We don't have influence in system
components though like QSQCLI, and you mentioned legacy software is
dependent on the presence of bugs, so changes there are an unknown.
From: OpenSource <opensource-bounces@xxxxxxxxxxxx> On Behalf Of Richard
Schoen via OpenSource
Sent: December 11, 2018 10:39 PM
Cc: Richard Schoen <Richard.Schoen@xxxxxxxxxxxxxxx>
Subject: Re: [IBMiOSS] XMLSERVICE, RPGLE & Java error
FUD only in the sense that there's no clarity from IBM on DB access layers.
Set up a town hall discussion and lay out the plans for us to have a rock
solid open source/PASE DB access mechanism for the go-forward.
Apparently there's a secret plan to improve DB access. In the spirit of
being open. Be open..... like Microsoft.
The point about XMLSERVICE is that it appears to be the best that IBM
currently has for open language DB access and it's based on basically a POC
as you described.
And other db layers are based on libdb400 which you mentioned on Ryver is
not thread-safe (unless I misunderstood your commentary), so not sure if
it's appropriate for .Net or any of the places libdb400 being used. Clarity
on that please since our choices for .Net are currently XMLSERVICE (which
works) and libdb400 (which kind of works and might be appropriate).
As you know Calvin is doing his best to synthesize libdb400 for .Net usage.
Let's continue to support him.
You also made it sound like IBM is endorsing or maybe just you are endorsing
microservice toolsets like ILEusion which are in their infancy as the future
of IBMi DB access to be the next gen of DB access. Cool, but not my choice
for general DB access only for app specific services that use the underlying
DB connectivity. Maybe I misunderstood your comments. If so you can correct
How bout just a couple slides with a bullet list on future DB access plans
that give all languages riding native on the i equal consistent access.
I want to be the guy supporting my apps, not supporting IBM's database
As said before I am happy to discuss this over the phone, in a webinar
meeting or we can bang away in the forums.
If you give me those directional bullets I would also be happy to put them
into a presentation as well.
I just want clarity for me and the developers I'm trying to guide to
maximize their usage of IBMi for development so others platforms don't take
Don't be offended if I continue pushing this issue because we need a roadmap
for developers to keep them from defecting to other platforms and consistent
DB access for IBMi with the built-in database is important.
I didn't know DB2 Connect was spin off..... Interesting.
Director of Document Management
I don't understand how any of this complaint ties in to XMLSERVICE or
ILEusion or any of that. As far as I'm concerned, they're completely
separate issues. And I don't understand your point about having to write
your own microservices. In fact a lot of the second half of your rant seems
like total ill-informed FUD, so I'm not going to even bother responding to
This is the IBMi Open Source Roundtable (OpenSource) mailing list To post a
message email: OpenSource@xxxxxxxxxxxx To subscribe, unsubscribe, or change
or email: OpenSource-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at https://archive.midrange.com/opensource
Help support midrange.com by shopping at amazon.com with our affiliate
As an Amazon Associate we earn from qualifying purchases.