Re: QWVRCSTK api returns value of N in Information-statusfield (solved)

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.