Hello
my understanding is that the ALWNULL option is for files processed by RPG
(declared in F specs or DCL-F ) .
it has no function if you use SQL statements embedded in RPG,...
Paul
From: rpg400-l-request@xxxxxxxxxxxx
To: rpg400-l@xxxxxxxxxxxx
Date: 15/10/2015 16:10
Subject: RPG400-L Digest, Vol 14, Issue 385
Sent by: "RPG400-L" <rpg400-l-bounces@xxxxxxxxxxxx>
message: 1
date: Thu, 15 Oct 2015 07:43:00 -0500
from: Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
subject: Does RPGLE handle NULL capability differently between
DDS-based and SQL-based files?
Just ran into this and I' m not sure what I'm seeing.
I have a table (SQL) that I'm using in an RPGLE program. It has
null-capable columns in it. The compile went fine - I had no control
option and CRTBNDRPG ALWNULL parameter = *NO.
I have an LF (DDS) over the table that I'm using in another RPGLE
program. The compile fails, saying there are null=capable fields.Adding
the ALWNULL setting made it work.
So does RPG default to ALWNULL in some form with SQL tables? By design?
Curious I am!
Vern
------------------------------
message: 2
date: Thu, 15 Oct 2015 08:53:33 -0400
from: darren@xxxxxxxxx
subject: Re: Does RPGLE handle NULL capability differently between
DDS-based and SQL-based files?
Was your SQL table created without the "not null with default" clause on
each field by chance?
This is some example source of how we create files:
create table PMGLS (
Year char(4) not null with default,
Period char(3) not null with default,
Account char(16) not null with default,
Company char(16) not null with default,
Customer char(12) not null with default,
Product char(48) not null with default,
Amount decimal(15, 2) not null with default,
Book char(10) not null with default
)
From: Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
To: RPG programming on the IBM i / System i
<rpg400-l@xxxxxxxxxxxx>
Date: 10/15/2015 08:43 AM
Subject: Does RPGLE handle NULL capability differently
between DDS-based
and SQL-based files?
Sent by: "RPG400-L" <rpg400-l-bounces@xxxxxxxxxxxx>
Just ran into this and I' m not sure what I'm seeing.
I have a table (SQL) that I'm using in an RPGLE program. It has
null-capable columns in it. The compile went fine - I had no control
option and CRTBNDRPG ALWNULL parameter = *NO.
I have an LF (DDS) over the table that I'm using in another RPGLE
program. The compile fails, saying there are null=capable fields.Adding
the ALWNULL setting made it work.
So does RPG default to ALWNULL in some form with SQL tables? By design?
Curious I am!
Vern
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/rpg400-l.
------------------------------
message: 3
date: Thu, 15 Oct 2015 07:59:31 -0500
from: Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
subject: Re: Does RPGLE handle NULL capability differently between
DDS-based and SQL-based files?
I am pretty sure that is not the case - because DSPFFD of the table
shows the fields as null-capable. DSPFFD of the logical shows the same
fields as null-capable.
BTW, the table is named TITLES - I duplicated the titles table that is
in the SQL Server pubs sample database. Basically used the CREATE TABLE
statement that would have been used there, modified as needed for IBM i.
On 10/15/2015 7:53 AM, darren@xxxxxxxxx wrote:
Was your SQL table created without the "not null with default" clause on
each field by chance?
This is some example source of how we create files:
create table PMGLS (
Year char(4) not null with default,
Period char(3) not null with default,
Account char(16) not null with default,
Company char(16) not null with default,
Customer char(12) not null with default,
Product char(48) not null with default,
Amount decimal(15, 2) not null with default,
Book char(10) not null with default
)
From: Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
To: RPG programming on the IBM i / System i
<rpg400-l@xxxxxxxxxxxx>
Date: 10/15/2015 08:43 AM
Subject: Does RPGLE handle NULL capability differently
between DDS-based
and SQL-based files?
Sent by: "RPG400-L" <rpg400-l-bounces@xxxxxxxxxxxx>
Just ran into this and I' m not sure what I'm seeing.
I have a table (SQL) that I'm using in an RPGLE program. It has
null-capable columns in it. The compile went fine - I had no control
option and CRTBNDRPG ALWNULL parameter = *NO.
I have an LF (DDS) over the table that I'm using in another RPGLE
program. The compile fails, saying there are null=capable fields.Adding
the ALWNULL setting made it work.
So does RPG default to ALWNULL in some form with SQL tables? By design?
Curious I am!
Vern
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.
------------------------------
message: 4
date: Thu, 15 Oct 2015 09:01:15 -0400
from: Charles Wilt <charles.wilt@xxxxxxxxx>
subject: Re: Does RPGLE handle NULL capability differently between
DDS-based and SQL-based files?
Vern,
I'm not aware of any differences, and my understanding is it shouldn't.
Are you sure about what you are saying? Are you sure the table has allow
null?
Same *LIBL for both compiles? Same compile command, CRTBNDRPG vs
CRTRPGMOD?
Check the compile listing to see actual options in effect for both
compiles. I'm wondering if you've got a RPGLEHSPEC data area affecting
one
compile but not the other.
Charles
On Thu, Oct 15, 2015 at 8:43 AM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
wrote:
Just ran into this and I' m not sure what I'm seeing.
I have a table (SQL) that I'm using in an RPGLE program. It has
null-capable columns in it. The compile went fine - I had no control
option
and CRTBNDRPG ALWNULL parameter = *NO.
I have an LF (DDS) over the table that I'm using in another RPGLE
program.
The compile fails, saying there are null=capable fields.Adding the
ALWNULL
setting made it work.
So does RPG default to ALWNULL in some form with SQL tables? By design?
Curious I am!
Vern
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.
------------------------------
message: 5
date: Thu, 15 Oct 2015 09:17:26 -0400
from: darren@xxxxxxxxx
subject: Re: Does RPGLE handle NULL capability differently between
DDS-based and SQL-based files?
I am pretty sure that is not the case - because DSPFFD of the table
shows the fields as null-capable. DSPFFD of the logical shows the same
fields as null-capable.
Oh no! I just realized you told me that the fields were null capable, and
I suggested checking to make sure they were not. My own pet peeve of
support not reading my statement, and I do it to someone else.
Anyway, the difference might be in how you're defining the fields in your
program. I assume with the logical referencing program, that you're using
RPG's ability to define the fields automatically? In the program
referencing the SQL table, perhaps you're defining those explicitly
somehow. Your explicit definition might be bypassing the null capable
definition in the file. I read through your post, and to the best of my
knowledge, you didn't already state this one...
------------------------------
message: 6
date: Thu, 15 Oct 2015 08:20:34 -0500
from: Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
subject: Re: Does RPGLE handle NULL capability differently between
DDS-based and SQL-based files?
Hi Charles
Your understanding is the same as mine. And I appreciate the questions -
so I looked at a couple listings. The one failure also had a mismatch on
program name and procedure name. So that's inconclusive.
So I changed the code back to no ALWNULL control or compile option, and
it compiled - even though there is a 0-severity message that says there
are NULL=capable fields in the file - same for both programs.
One thing different about both - I am using an OAR handler - I've not
done the NULL-capability processing into the handler, and RPG isn't
telling me that the columns ARE null-capable, even though it knows. And
sending data back, RPG doesn't stop it.
So I suspect that IF I return an indication that a field is null, that
the program might blow up, unless I add the alwnull option - we shall see!
Thanks, man!
Vern
On 10/15/2015 8:01 AM, Charles Wilt wrote:
Vern,
I'm not aware of any differences, and my understanding is it shouldn't.
Are you sure about what you are saying? Are you sure the table has
allow
null?
Same *LIBL for both compiles? Same compile command, CRTBNDRPG vs
CRTRPGMOD?
Check the compile listing to see actual options in effect for both
compiles. I'm wondering if you've got a RPGLEHSPEC data area affecting
one
compile but not the other.
Charles
On Thu, Oct 15, 2015 at 8:43 AM, Vernon Hamberg
<vhamberg@xxxxxxxxxxxxxxx>
wrote:
Just ran into this and I' m not sure what I'm seeing.
I have a table (SQL) that I'm using in an RPGLE program. It has
null-capable columns in it. The compile went fine - I had no control
option
and CRTBNDRPG ALWNULL parameter = *NO.
I have an LF (DDS) over the table that I'm using in another RPGLE
program.
The compile fails, saying there are null=capable fields.Adding the
ALWNULL
setting made it work.
So does RPG default to ALWNULL in some form with SQL tables? By design?
Curious I am!
Vern
--
This is the RPG programming on the IBM i (AS/400 and iSeries)
(RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.
------------------------------
message: 7
date: Thu, 15 Oct 2015 08:26:42 -0500
from: Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
subject: Re: Does RPGLE handle NULL capability differently between
DDS-based and SQL-based files?
LOL - BTDT - no T-shirt
I replied to Charles after checking things again - the wild card here is
that I'm using an OAR handler - and I've not tried processing the tables
WITHOUT the handler.
OK, I took out the handler - compile still completed. But running the
program got an error due to the column that is null.
When run with the handler, it doesn't get an error - but that's probably
because I have to return the NULL-capability state for the fields.
More work to do!!
Thanks
Vern
On 10/15/2015 8:17 AM, darren@xxxxxxxxx wrote:
I am pretty sure that is not the case - because DSPFFD of the table
shows the fields as null-capable. DSPFFD of the logical shows the same
fields as null-capable.
Oh no! I just realized you told me that the fields were null capable,
and
I suggested checking to make sure they were not. My own pet peeve of
support not reading my statement, and I do it to someone else.
Anyway, the difference might be in how you're defining the fields in
your
program. I assume with the logical referencing program, that you're
using
RPG's ability to define the fields automatically? In the program
referencing the SQL table, perhaps you're defining those explicitly
somehow. Your explicit definition might be bypassing the null capable
definition in the file. I read through your post, and to the best of my
knowledge, you didn't already state this one...
------------------------------
message: 8
date: Thu, 15 Oct 2015 10:10:13 -0400
from: Charles Wilt <charles.wilt@xxxxxxxxx>
subject: Re: Does RPGLE handle NULL capability differently between
DDS-based and SQL-based files?
Vern,
So do you get the same 0-severity message on compile for both programs? Or
does the one with the logical fail to compile?
From the manual, "If ALWNULL(*NO) is specified, then you cannot process
records with null-value fields from externally
described files. If you attempt to retrieve a record containing null
values, no data in the record will be
accessible and a data-mapping error will occur."
So it would seem that successful compile with a run-time error is to be
expected. It also makes sense to me that you wouldn't see the run-time
error with the OAR handler as the handler is now responsible for data i/o
instead of the RPG / OS run time.
Charles
On Thu, Oct 15, 2015 at 9:26 AM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
wrote:
LOL - BTDT - no T-shirt
I replied to Charles after checking things again - the wild card here is
that I'm using an OAR handler - and I've not tried processing the tables
WITHOUT the handler.
OK, I took out the handler - compile still completed. But running the
program got an error due to the column that is null.
When run with the handler, it doesn't get an error - but that's probably
because I have to return the NULL-capability state for the fields.
More work to do!!
Thanks
Vern
On 10/15/2015 8:17 AM, darren@xxxxxxxxx wrote:
I am pretty sure that is not the case - because DSPFFD of the table
shows the fields as null-capable. DSPFFD of the logical shows the same
fields as null-capable.
Oh no! I just realized you told me that the fields were null capable,
and
I suggested checking to make sure they were not. My own pet peeve of
support not reading my statement, and I do it to someone else.
Anyway, the difference might be in how you're defining the fields in
your
program. I assume with the logical referencing program, that you're
using
RPG's ability to define the fields automatically? In the program
referencing the SQL table, perhaps you're defining those explicitly
somehow. Your explicit definition might be bypassing the null capable
definition in the file. I read through your post, and to the best of
my
knowledge, you didn't already state this one...
--
midrange.com
