Thanks again, Scott and one more question - to the program author.
I've realized that Oracle connection string delivered to me by the
ORacle admin is somehow - longer than 256 bytes.
Can I change the definitions of "url" in JDBC_ConnProp and
JDBC_Connect to something longer - 512, for example?

TIA,
J.A.


On Fri, Dec 16, 2016 at 11:50 PM, Scott Klement <c400-l@xxxxxxxxxxxxxxxx> wrote:
Jevgeni,

RPG always passes a minimal operational descriptor (one where the count of
parameters is passed.) Usually, that is only used when an RPG procedure has
options(*NOPASS) on a parameter.

JDBCR4 currently only uses this feature for null indicators, so you can get
by with only adding #pragma descriptor to those. But, if in the future, you
wish to call any other RPG procedure that uses options(*NOPASS) (potentially
for other things) you'll want to be sure to add the #pragma there, too.

On a similar note, when RPG has options(*omit), that means that you can pass
a NULL pointer for that parameter if you wish. Since the null indicators
in JDBCR4 use *OMIT (in addition to *NOPASS) if you don't want to use a null
indicator sometimes, you could pass a NULL pointer for the null indicator
parameter.

Hope that helps...





On 12/16/2016 8:30 AM, Jevgeni Astanovski wrote:

In fact I have already solved the problem.
A little googling around for "operational descriptor"....

I just had to modify my header file and add one row for JDBC_GetCol:

#pragma descriptor(void JDBC_GETCOL(void , void, ""))

With this RPG understood, that number of parameters is 3 and returned
me the correct value of nullInd.


Of course also added the same pragma to all other functions that deal
wit nullInd - just in case...

Thanks,

Jevgeni.


On Fri, Dec 16, 2016 at 4:04 PM, Ron Unknown <qgenesist@xxxxxxxxxxx>
wrote:

Jevgeni,

I am not sure, it has been so long since I have messed with 400s, but is
the pointer given an initial value before calling the program? something
like:

Dcl Y-Ptr * init(*null) or based(*null)

not sure of the syntax any more, before it is called so that the sytem
knows it is a pointer?


________________________________
From: C400-L <c400-l-bounces@xxxxxxxxxxxx> on behalf of Jevgeni
Astanovski <jevgeniast@xxxxxxxxx>
Sent: Friday, December 16, 2016 2:55 AM
To: Bare Metal Programming IBM i (AS/400 and iSeries)
Subject: [C400-L] Misunderstanding with JDBCR4

Hi, collegues
Having a challenge of accessing external database from my ILE/C
program, looked at Scott Klement JDBCR4.
As I do not write RPG, had to spend some time porting library header
from RPG to C. Not a big job.
Generally works fine.
However when I tried to see how JDBC_GetCol returns NullInd in case
field is empty, ran into a problem.

JDBC_GetCol is prototyped so:

VAR32767 JDBC_GETCOL(RESHANDLE *, int, char *) ;
VAR32767 and RESHANDLE are my defined types and they work fine.

I call this function in my program:

RESHANDLE rs ;
char NullInd ;
VAR32767 Field ;

Field = JDBC_GETCOL(&rs, 48, &NullInd) ;

It returns field value fine, however NullInd is always unchanged -
field is empty or not.
Run in debugger mode to see what Scott's program does.
His function looks so:

P JDBC_GetCol B export
D JDBC_GetCol PI 32767A varying
D rs like(ResultSet)
D col 10I 0 value
D nullInd 1N options(*nopass:*omit)
D result s 32767A varying
D str s like(jstring)
D null s 1N inz(*OFF)

/free

jdbc_begin_object_group(5);

monitor;
str = getColString(rs: col);
if (str = *NULL);
result = '';
null = *ON;
else;
result = r(str);
endif;
on-error;
null = *ON;
result = '';
endmon;
jdbc_end_object_group();
if (%parms >= 3 and %addr(nullInd)<>*NULL);
nullInd = Null;
endif;

return result;

/end-free

Sorry for the formatting...

What my debugging show is that Null variable has a proper value, but
is never assigned to nullInd.
I added NumParms variable and assigned value of %parms to it.
From that I saw that NumParms is -1, however all 3 parameters are passed.

Had a look at the manual for %parms.
It says the following:
"The value returned by %PARMS will be -1 if the system can determine
that the operational
descriptor was not passed, but in some cases when the system cannot
detect this,
the value returned by %PARMS may be an incorrect value that is zero or
greater."

Is there anything I can do about it?

Any advise will be highly appreciated...

Jevgeni.
--
This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L)
mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
C400-L Info Page -
midrange.com<http://lists.midrange.com/mailman/listinfo/c400-l>
lists.midrange.com
The topic of the list is C, C++, and MI Programming on and for the IBM i
(AS/400 and iSeries). This includes programming on other platforms in C/C++
when it RELATES ...



or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.
midrange.com -- C400-L mailing list
archive<http://archive.midrange.com/c400-l>
archive.midrange.com
midrange.com C400-L mailing list archive




--
This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L)
mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.

--
This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L)
mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.


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