Re: SQL Indicator Arrays

[Jon Paris <jon.paris@xxxxxxxxxxxxxx>]

I’ve not seen that on Kevin - wanna save us some time and give us the URL?


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

> On Nov 17, 2016, at 7:55 PM, Kevin Wright <kevin.wright@xxxxxxxxxxxx> wrote:
>
> 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.