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



Hi Buck,

This wouldn't be anything to do with the "Terminate debug session on program completion" preference in Run/Debug>IBM I Debug?

I know I have problems with debugging a program that did a similar thing and had to be called multiple times.

Anyway, just a thought.

Best regards,
Mark Austin
IT Consultant
Universal Music Publishing Group
Email: mark.austin@xxxxxxxxxx
Tel: +44 (0) 20 8742 5520
Fax: +44 (0) 20 8742 5699
Post: 347-353 Chiswick High Road, London W4 4HS
Universal Music Publishing International Limited
Registered in England. Number 02050403
Registered Office: 20 Fulham Broadway, London, SW6 1AH


-----Original Message-----
From: wdsci-l-bounces@xxxxxxxxxxxx [mailto:wdsci-l-bounces@xxxxxxxxxxxx] On Behalf Of Buck Calabro
Sent: 27 January 2014 20:31
To: wdsci-l@xxxxxxxxxxxx
Subject: [WDSCI-L] RDi 9.0.1 How to debug UDTF with SEP?

Question: Is there a special setting I need to make in order to debug a user defined table function which is written in ILE RPG?

Details:
I'm making my first foray into writing a User Defined Table Function in ILE RPG. I thought I had some issues understanding the mapping between the CREATE FUNCTION and the RPG parameter list, so I thought I'd make a stub, fire up IBM i Navigator's Run SQL function, put the RPG in SEP debug and look at the values for the fetch in debug.

For those unfamiliar with the way an RPG UDTF works, the database CALLs the RPG program multiple times to fulfill a single table() request. One of the parameters the database provides is the 'call type'. So:

select * from table(table(buck.sqludtf(3)) as src;

1) DB calls SQLUDTF with call type -1 (open)
RPG program does an OPEN CURSOR
2) DB calls SQLUDTF with call type 0 (fetch)
RPG program does a FETCH NEXT
RPG program sets the outbound SQLSTATE
RPG program returns
3) DB checks SQLSTATE returned by RPG program.
If SQLSTATE normal, repeat step 2
Otherwise, DB calls SQLUDTF with call type 1 (close)
4) DB collates the returned 'rows' from the RPG program into an SQL table and presents the table to the rest of the SQL statement.

The RPG program runs, fires the SEP debugger, and I can step through the 'open' section with no problem. The RPG does the return (as expected) and then the SEP debugger reports that the program terminated and the results show up in the SQL Navigator window! I expected that the SEP debugger would go through at least one each of 'open', 'fetch' and 'close', since the program itself did, but that doesn't happen.

Recap:
The UDTF works fine. It does get called multiple times and the program code physically executes, as I can see the results. The SEP debugger only stops during the first pass through the program. The green screen debugger STRDBG works as expected (stopping during every invocation of the program).

--buck
--
This is the Rational Developer for IBM i / Websphere Development Studio Client for System i & iSeries (WDSCI-L) mailing list To post a message email: WDSCI-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at http://archive.midrange.com/wdsci-l.


________________________________

“**Confidentiality**
The information contained in this e-mail is confidential, may be privileged and is intended solely for the use of the named addressee. Access to this e-mail by any other person is not authorised. If you are not the intended recipient, you should not disclose, copy, distribute, take any action or rely on it and you should please notify the sender by reply. Any opinions expressed are not necessarily those of the company.

We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.