× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



OK. Just got a chance to read thru the "Is this an SQL problem or
quirk" thread. Now, I'm wondering if I should request to change the
default of IGNORE_DERIVED_INDEX *NO to *YES.

If you're creating a PMR, please keep me updated on IBM's finding.
Note: IBM has been very helpful on resolving my issue. But, IBM has
also told me that they do not plan to fix that problem that they found
on CQE not handling interrupt. So, my only option is to change the
default to *YES.



"Alan Shore" <AlanShore@xxxxxxxx> wrote in message
news:<mailman.2422.1234291055.26163.rpg400-l@xxxxxxxxxxxx>...

Sorry Lim - I'm getting my e-mail threads all mixed up.
However, your response of "adding IGNORE_DERIVED_INDEX *YES to the
QAQQINI
file" has caused us some problems in itself.
Please see the thread entitled
Is this an SQL problem or quirk



Alan Shore
Programmer/Analyst, Distribution
E:AShore@xxxxxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill

__________________

Lim
MUCH appreciated for your response.
I will pass this on


Alan Shore
Programmer/Analyst, Distribution
E:AShore@xxxxxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill

rpg400-l-bounces@xxxxxxxxxxxx wrote on 02/10/2009 01:11:18 PM:

IBM has found the cause of the problem and the problem has been
resolved
by adding IGNORE_DERIVED_INDEX *YES to the QAQQINI file. See below
for
IBM's explanation on cause of problem:


<Clip - Comment From IBM>
Our developers have found some interesting info while testing this.
To
make a long story short, the problem appears to be because the SQL
is
going down our CQE path (older query engine) rather than the newer
SQE
path (newer query engine). When CQE is used, interrupts are not
being
handled and therefore the call stack info is not available when the
code
is down in SLIC. When SQE is use, the interrupts are handled
correctly
and the snapshot can be taken.

The developers did find that CQE can handle getting the callstack of
the
thread running in if the option of 1 is used for the API, however
that
is probably not what you need here. The main thread (with option 2)
specified is the one that cannot be obtained.

If we can determine why the SQL is going down the CQE path and
change
that to use SQE, that may resolve the issue for you.
Are you currently using a QAQQINI file or are you aware of any
reason
why CQE is being used in this case?

It would be very helpful if you could collect a *DETAILED DBMON for
us
of this issue. Let me know if this would be possible and if you
need
info on how to do that I can send that to you. Actually I will
include
the info below ---

Do the following as quick as possible so that the DBMON does not
have to
run long, that will reduce the number of records.

CRTLIB IBMSUP
STRDBMON OUTFILE(IBMSUP/UDFMON) JOB(*ALL) TYPE(*DETAIL)
INCSYSSQL(*YES)
reproduce the failure
ENDDBMON JOB(*ALL)

Then create a savefile, save the DBMON file to it, and send in to
me.

Thanks,

</Clip - Comment From IBM>


Thanks

"Lim Hock-Chai" <Lim.Hock-Chai@xxxxxxxxxxxxxxx> wrote in message
news:<mailman.2184.1232640421.21608.rpg400-l@xxxxxxxxxxxx>...
Our admin reported this bug to IBM and IBM's respond is not what I
excepted. Our admin said that IBM told him that this api will only
work
when calling directly from a HLL program. It will not work when it
is
called from a UDF (Not a HLL program). So, IBM does not plan to
correct
this issue :(.



"Flensburg, Carsten" <Flensburg@xxxxxxxxxx> wrote in message
news:<mailman.1619.1232481805.21608.rpg400-l@xxxxxxxxxxxx>...

The QWVRCSTK API documentation reveals no restrictions that could
explain the problem you're experiencing, so I'd suggest that you do
report this issue to IBM.

Best regards,
Carsten Flensburg

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Lim Hock-Chai
Sent: 20. januar 2009 16:24
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: QWVRCSTK api returns value of N in Information-status
field

I wonder if I should report this as a bug to IBM?

"Lim Hock-Chai" <Lim.Hock-Chai@xxxxxxxxxxxxxxx> wrote in message
news:<mailman.1460.1232462474.21608.rpg400-l@xxxxxxxxxxxx>...
Thanks Carsten. unfortunately, I'm already using the value of 2.
See
below:
D JobIDInfoDS DS
D JobName 10 Inz('*')
D JobUser 10 Inz( *Blank )
D JobNbr 6 Inz( *Blank )
D 16 Inz( *Blank )
D 2 Inz( *AllX'00' )
D 10I 0 Inz( 2 )
D 8 Inz( *AllX'00' )

D JobIDFmt S 8 Inz( 'JIDF0100' )

"Flensburg, Carsten" <Flensburg@xxxxxxxxxx> wrote in message
news:<mailman.1401.1232436686.21608.rpg400-l@xxxxxxxxxxxx>...
Hello Lim,

There's an option on the QWVRCSTK API job identification parameter
format JIDF0100 to specify that the stack information should be
retrieved for the initial thread of the identified job. If you
haven't
already done so, you could try and set the Thread indicator in the
JIDF0100 job identification format to a value of 2, and see how that
turns out?
----------
----------
--
This is the RPG programming on the IBM i / System i (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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.