Re: SQL Indicator Arrays

[Marco Facchinetti <marco.facchinetti@xxxxxxxxx>]

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=97341

HTH

--
Marco Facchinetti

Mr S.r.l.

Tel. 035 962885
Cel. 393 9620498

Skype: facchinettimarco

2016-11-18 1:55 GMT+01:00 Kevin Wright <kevin.wright@xxxxxxxxxxxx>:

> I believe that there is an existing (raised in the last month) RFE to
> harmonise the processing of fields having the null attribute in RPG via:
> 1. Native I/O
> 2. Embedded SQL I/O
> 3. RPG Triggers
>
> Wouldn't this be a better RFE to get behind? This could obviate the
> necessity for SQL Indicator arrays and would mean having one way of
> checking / setting null no matter the source of the null. As for whether it
> would ever actually be done ...
>
> Regards,
>
> Kevin Wright
>
> -----Original Message-----
> From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
> Jon Paris
> Sent: Friday, 18 November 2016 11:43 AM
> To: Midrange-L Midrange-l <midrange-l@xxxxxxxxxxxx>
> Subject: Re: SQL Indicator Arrays
>
> 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.
>
> --
> 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.