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



I think RFE’s work better when we use them to request things that we might have a hope in hell of getting Alan. And frankly I don’t see this ever happening - it would require major effort on the part of both the SQL and RPG teams - and for what? Not a lot of benefit really.

I lost a battle 20+ years ago on this topic and I’m just happy that we are now in a situation where the SQL precompiler at least keeps up with the compiler.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Nov 17, 2016, at 5:37 PM, Alan Campin <alan0307d@xxxxxxxxx> wrote:

But all of this ignores what should be the basic RFE. Make SQL Native to
RPG instead of a pre-compiler generating RPG.

RPG team extracts SQL statements as it compiles and makes function call to
SQL team functions that parse and analyze SQL statements building internal
tables accessed through API calls to build functions calls that run SQL
statements.

As far as RPG is concerned, SQL is native and RPG team can write optimized
code to access SQL functions.

Then things like nulls indicators become basic. Just as if it was an null
indicator in a file. Stored internally, accessed via a function.

I know IBM will never approve but it is my dream.

The one thing we should be asking for as far as SQL and RPG is concerned is
making SQL native.

On Thu, Nov 17, 2016 at 2:25 PM, Barbara Morris <bmorris@xxxxxxxxxx> wrote:

On 11/17/2016 3:27 PM, dlclark@xxxxxxxxxxxxxxxx wrote:

"MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx> wrote on 11/16/2016
11:15:45 AM:

On the flip side, it is a nuisance (to me) to have to manually
create and maintain such a data structure. So, has anybody come up with

a

means of automatically generating an SQL indicator array with an

overlaid

data structure that matches the RPG-generated data structure for an
external SQL view reference? If not, maybe it is time for an RFE?


I created the RFE for an extension to the LIKEDS keyword to
support this.


Hi Dave, I added a comment to the RFE basically asking you to change it to
reflect what I think is the underlying requirement to obtain an
externally-described data structure with the SQL style of null indicator
rather than to describe it in terms of a general LIKEDS enhancement.

I think the RFE will probably get more votes if it's about RPG supporting
the SQL style of null indicator.

Just as an aside, it's usually better (in terms of attracting votes) to
describe an RFE in terms of the underlying requirement rather than in terms
of a suggested implementation.

--
Barbara


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

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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.