Re: Road Map to move a home grown application from RPG to DB2 SQL or to any other data base platform

Hi Birgitta

I don't usually doubt things you say - so thanks for the reply.

I did go looking for that QAQQINI option and found that this does not seem to apply to all native RPG I/O - it seems to be limited to opening views, partitioned tables with some condition, and tables with RCAC. And if opened for *OUTPUT only, SQE is not used.

I suspect that RPG makes a request to the DB component, and then that component decides how the request is carried out. It seems that RPG should not have to figure out what to call based on these conditions - this is an optimizer thing. I'll be interested to talk to Scott and Barbara some convenient time, this is interesting stuff for several reasons for me.

It would seem that this also applies to other languages - the change is in how files are opened, and that can occur in CL or COBOL or C. It's not a language thing, it's a database thing.

Here is the item from Knowledge Center on the QAQQINI option -

With 7.2, some native database access begins to use SQE by default, including:

* Work with Query (WRKQRY) command, when one of the run options is used
* Run Query (RUNQRY) command
* Open Query File (OPNQRYF) command
* Open Data Base File (OPNDBF) command or Native database I/O where
the target of the open is an SQL view, or a partitioned table and
aMBR(*ALL)override is being used unless the open is for *OUTPUT only
* Any open of a database file where a Row Permission or Column Mask is
defined and enabled, unless the open is for *OUTPUT only


Cheers
Vern


On 1/18/2017 12:01 AM, Birgitta Hauser wrote:

Vern,

Regarding Birgitta's comment about native I/O using SQE - I don't believe

that is the case -
It was Barbara Morris who told it and Scott Forstie confirmed.
For being able to implement RCAC (Row and Column Access Control - introduced
with 7.2) all data access to the database must be performed with the SQE.
There is an option SQE_NATIVE_ACCESS in the QAQQINI file which allows
non-SQL interfaces (such as Query/400 and OPNQRYF) being rerouted to the
CQE.
If SQE_NATIVE_ACCESS is set to *NO RCAC cannot be used.

I don't want to start a new discussion, because none of us is deeply
involved how it really works under the cover.

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
„Train people well enough so they can leave, treat them well enough so they
don't want to.“ (Richard Branson)


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Vernon Hamberg
Sent: Mittwoch, 18. Januar 2017 04:35
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: Road Map to move a home grown application from RPG to DB2 SQL
or to any other data base platform

Regarding Birgitta's comment about native I/O using SQE - I don't believe
that is the case - both SQL and RPG make requests to the underlying DB
components, so far as I remember conversations I've had. I mean, if SQE were
used, there would not be the issue with FIELDPROC and encryption over key
fields.

On 1/17/2017 1:48 PM, Nathan Andelin wrote:
-snip-

BTW beginning with release 7.2. all data access including QUERY/400,

OPNQRYF, native I/O is executed with the SQL Query Engine.

In regards to QUERY/400 and OPNQRYF using the SQE, that's progress. I
remember the announcement.

In regards to native I/O using SQE, I'm not sure what you're referring to.

This is not what I'm sure about either - I would need to see the
announcement - the one I remember is that at 7.2 all QUERY requests were
using SQE.

Note that Vern's point, and my point pertain to PF and Indexes being
essentially identical. SQL Views and Materialized Query Tables
obviously don't have precise counterparts under DDS.

Just a side comment - PF and tables are the equivalents I mentioned - the
same MI object type code of x1901, as I recall.

Views and indexes are implemented as LFs - I've not done the DMPOBJ to find
the MI object type.

All of these are children of lower-level space objects - gotta love the
object-based nature of this our favorite system!

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

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link:
http://amzn.to/2dEadiD