Re: AW: Select * into an external DS, and then adding columns -- MIDRANGE-L

Hi Rob,

It appears the program wasn't compiled with debug info.
Check the default values for the create commands and use CHGCMDDFT to
change them.

We have the following command defaults:
CRTBNDCL DBGVIEW(*ALL)
CRTBNDRPG DBGVIEW(*ALL)
CRTCLMOD DBGVIEW(*ALL)
CRTRPGMOD DBGVIEW(*ALL)

I'm not sure why we have CRTSQLRPGI with DBGVIEW(*NONE) when there is an
option for DBGVIEW(*SOURCE).

Yours truly,

Glenn Gundermann
Email: glenn.gundermann@xxxxxxxxx
Work: (416) 675-9200 ext. 89224
Cell: (416) 317-3144

On 8 February 2016 at 07:47, <rob@xxxxxxxxx> wrote:

Actually, when I ran STRDBG I didn't specify a program name. Kind of like
the old way of getting index advice.
If I try to actually debug this program I get
CPF9C15
Message . . . . : Program ACR125B cannot be debugged.
Cause . . . . . : The modules that are bound to program ACR125B of type
*PGM
in library ERPLXPTFO were not compiled with the proper debug option or
debug
information has been removed from this program.
Recovery . . . : Compile the modules with the proper debug option
specified
and bind program ACR125B again.

There were numerous messages at the beginning that I'll append later to
this email but in the area of concern I have:

**** Ending debug message for query .
ODP created.
Blocking used for query.
ODP not deleted.
Embedded SELECT completed.
ODP reused.
ODP not deleted.
Embedded SELECT completed.
1 rows fetched from cursor C.
ODP reused.
ODP not deleted.
Embedded SELECT completed.
ODP reused.
ODP not deleted.
Embedded SELECT completed.
1 rows fetched from cursor C.
ODP reused.
ODP not deleted.
Embedded SELECT completed.
ODP reused.
ODP not deleted.
Embedded SELECT completed.
1 rows fetched from cursor C.
...
ODP reused.
ODP not deleted.
Row not found for SELECT.
ODP reused.
ODP not deleted.
Embedded SELECT completed.
Row not found for C.
ODP deleted.
Cursor C was closed.

SQL7963
Message . . . . : 1 rows fetched from cursor C.
Cause . . . . . : 1 rows were fetched from cursor C with result set
identifier 0. If the result set identifier is non-zero, this cursor was
being accessed as a stored procedure result set.

Beginning messages:

Ownership of object QBND073125 in QTEMP type *USRSPC changed.
Query options retrieved file QAQQINI in library QUSRSYS.
**** Starting optimizer debug message for query .
The query access plan has been rebuilt.
All access paths were considered for file RCO.
Additional access path reason codes were used.
Access path of file RCOL01 was used by query.
Access path suggestion for file RCO.
Access path suggestion for file RCO.
Query options used to build the query access plan.
**** Ending debug message for query .
ODP created.
Blocking used for query.
Cursor C opened.
Data conversion required on FETCH or embedded SELECT.
1 rows fetched from cursor C.
Query options retrieved file QAQQINI in library QUSRSYS.
**** Starting optimizer debug message for query .
The query access plan has been rebuilt.
All access paths were considered for file RCX.
Arrival sequence access was used for file RCX.
Query options used to build the query access plan.
**** Ending debug message for query .
ODP created.
Blocking used for query.
ODP not deleted.
Embedded SELECT completed.
Query options retrieved file QAQQINI in library QUSRSYS.
**** Starting optimizer debug message for query .
The query access plan has been rebuilt.
Access path of file RCOL04 was used by query.
Query options used to build the query access plan.
**** Ending debug message for query .

SQL7919
Message . . . . : Data conversion required on FETCH or embedded SELECT.
Cause . . . . . : Host variable CRSTS requires conversion. The data
retrieved for the FETCH or embedded SELECT statement can not be directly
moved to the host variables. The statement ran correctly. Performance,
however, would be improved if no data conversion was required. The host
variable requires conversion for reason 7.
-- Reason 7 - a data conversion was required on the mapping of the value
being retrieved to host variable CRSTS, such as a CCSID conversion.

CRSTS is a column that has always been in this table. Consider it the
"active record code".

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

From: "Birgitta Hauser" <Hauser@xxxxxxxxxxxxxxx>
To: "'Midrange Systems Technical Discussion'"
<midrange-l@xxxxxxxxxxxx>
Date: 02/06/2016 05:56 AM
Subject: AW: Select * into an external DS, and then adding columns
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>

Did you check the SQLCODE immediately after the fetch?
Didn't you get SQLCODE 30?

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"

-----Ursprüngliche Nachricht-----
Von: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von
rob@xxxxxxxxx
Gesendet: Friday, 05.2 2016 19:46
An: midrange-l@xxxxxxxxxxxx
Betreff: Select * into an external DS, and then adding columns

Scenario:

You have something like this:
D RCODS E DS EXTNAME(RCO)
C/EXEC SQL
C+ DECLARE C CURSOR FOR
C+ SELECT * FROM RCO
C+ WHERE CMPNY BETWEEN :
C+ W1LWCO AND :W1UPCO AND CRSTS = 'A'
C+ ORDER BY CMPNY FOR FETCH ONLY
C/END-EXEC
C/EXEC SQL
C+ OPEN C
C/END-EXEC
C/EXEC SQL
C+ FETCH C INTO :RCODS
C/END-EXEC
You add a column to the table, and do NOT recompile this program.
Therefore the external DS doesn't match.
ALTER TABLE RCO
ADD COLUMN ...

I thought (many releases ago) that this used to generate a mild warning.
Then it became a hard halt.
I just tried it with seclvl 0 logging and STRDBG running and no warning
whatsoever. The data came from the cursor and worked just fine.

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail
to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

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