Re: SQL Indicator Arrays -- MIDRANGE-L

Thanks - not sure I like it but …

Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Nov 18, 2016, at 6:48 AM, Marco Facchinetti <marco.facchinetti@xxxxxxxxx> wrote:

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.

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