Re: Problem with SQL UDF

I have not had a chance to debug this further [somehow I managed to get my process in a deadlock; which I did not yet start to debug], but I can confirm the same results on v5r3 & v5r4. I had assigned RLIB and RVAR to have non-blank defaults, for a quick review before further debug. The RVAR is reset to blanks sometime after the call to the API and before the source statement immediately following; not back to it yet.

Thus for /Why?/, it would seem reasonable to just report this as a defect.

FWiW to confirm visually that the CALL transpires to QUSROBJD for the case of /returns blanks/ versus /gives error/, can be achieved easily with debug using ADDBKP '/1' or review of trace output.

Regards, Chuck
--
All comments provided "as is" with no warranties of any kind whatsoever and may not represent positions, strategies, nor views of my employer

Dr.UgoGagliardelli wrote:
I created this simple UDF that should return the library of a file in library list:

CREATE FUNCTION GETLIB
(RFIL VARCHAR(10)) RETURNS VARCHAR(10)
LANGUAGE SQL NOT DETERMINISTIC
SET OPTION DBGVIEW = *SOURCE, DYNUSRPRF = *OWNER, USRPRF= *OWNER,
COMMIT=*NONE, EVENTF=*NO
BEGIN
DECLARE RLIB VARCHAR(10);
DECLARE RVAR CHAR(48) DEFAULT ' ';
DECLARE RLEN INT DEFAULT 48;
DECLARE RFMT CHAR(8) DEFAULT 'OBJD0100';
DECLARE ROBJ CHAR(20) DEFAULT ' ';
DECLARE RTYP CHAR(10) DEFAULT '*FILE ';
SET ROBJ = CHAR(RFIL, 10) CONCAT CHAR('*LIBL', 10);
CALL QUSROBJD (RVAR, RLEN, RFMT, ROBJ, RTYP);
SET RLIB = TRIM(SUBSTR(RVAR, 39, 10));
RETURN RLIB;
END;

The problem is that RVAR, after the call is always empty disregarding the file was found or not. If the file is not found the function ends in error, due to the missing API error structure (with a CPF9812 in the joblog as expected), running under debug I can see in the joblog that QUSROBJD was called successfully, if I change the proc name with something that doesn't match a program or service-program name, I can see in the joblog that the program was not found in *LIBL (SQL0204), so I'm pretty sure that the call takes place.
In SQL reference, I found that, if not explicitly declared in a declare procedure statement, all arguments inside a variable will be considered of type INOUT, so I assumed that should run as is, but it's not.
Why?
.

Relevant Pages

  • Re: bad dll calling convention in debug only
    ... >> Are you also using the debug version of the MFC library? ... >> debugging the DLL. ... >> Create a typelib and use that to replace the Declare Directives. ... I also recommend Bruce McKinney's source for a WinAPI typelib. ...
    (microsoft.public.vb.general.discussion)
  • Re: Problem with SQL UDF
    ... Debug shows all is correct, *except* the representation of the result by the SQL. ... That would indicate a result of C-null-string for declarations of the data as a string -- which a SQL CHAR declaration presumably, and as I recall, is; though I did not review the listing. ... Try instead, DECLARE RVAR BINARY, and see how that functions. ...
    (comp.sys.ibm.as400.misc)
  • Re: object refrence not set to an instance of an object ??
    ... but every time i run the subroutine, i get an "Object reference ... also, wenn i set a breakpoint to debug it, de breakpoint red point's ... get a question mark in it. ... > Try instantiating the 'line' variable when you declare it (Dim line As ...
    (microsoft.public.dotnet.languages.vb)
  • Re: scope of a variable
    ... "Brett Foster" wrote in message ... > Kenneth wrote: ... > It's hard enough to debug code... ... > even declare all your variables in the fragment. ...
    (comp.lang.java.help)
  • Re: scope of a variable
    ... Kenneth wrote: ... It's hard enough to debug code... ... even declare all your variables in the fragment. ... Brett ...
    (comp.lang.java.help)