Re: SQL Indicator Arrays

[Alan Campin <alan0307d@xxxxxxxxx>]

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.