|
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.
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
