Hi Jevgeni,

I do not remember exactly what would need to be increased, but you should have all of the source code and can make these changes in your copy...

So, yes.. go ahead and make it 512 or whatever works for you, and just make sure that it is changed in any/all other places that this gets used.

-SK


On 1/6/2017 2:52 AM, Jevgeni Astanovski wrote:
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 ...

Replies:

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