Re: Misunderstanding with JDBCR4

Thanks, Scott.
This helped and I now clearer understand the idea beyond operational descriptor.
OK. So it works.

Just a brief review of your service program usage.
I wrote an ILE/C program that accesses MSSQL. Works fine, almost no problems.
However the goal was to access Oracle.
It was sort of challenge. I did everything according to the examples
and understanding, however always got an error in JDBC_ConnProp,
saying that Network Adapter could not establish connection.
My guess was that it is an answer from Oracle, however both network
people and Oracle admin said that they see absolutely no traffic from
AS/400 to Oracle server.
That was strange. Changed server address in connection string to
"localhost" - exactly the same result.
So this error probably comes from JDBC driver.

Spent a couple of hours googleing and trying different opportunities -
no result.
Then tried to change job CCSID from our default 1122 to 37.
Surprise-surprise - everything started to work!
Funny thing is that it was not required for MSSQL - only for Oracle.
Driver pecularity, probably.

If someone will need to access external databases from ILE/C and lazy
to port Scott's RPG headers to C headers - drop me an e-mail, I'll
share it.
Scott C. Klement copyright is retained, of course :-)

Merry Christmas wishes,

J.A.


On Fri, Dec 16, 2016 at 11:50 PM, Scott Klement <[email protected]> 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 <[email protected]>
>> 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-Zwy7GipZuJhWk0Htik3J/[email protected]> on behalf of Jevgeni
>>> Astanovski <[email protected]>
>>> 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-Zwy7GipZuJhWk0Htik3J/[email protected]
>>> 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-Zwy7GipZuJhWk0Htik3J/[email protected]
>>> 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-Zwy7GipZuJhWk0Htik3J/[email protected]
>>> To subscribe, unsubscribe, or change list options,
>>> visit: http://lists.midrange.com/mailman/listinfo/c400-l
>>> or email: C400-L-request-Zwy7GipZuJhWk0Htik3J/[email protected]
>>> 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-Zwy7GipZuJhWk0Htik3J/[email protected]
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/c400-l
> or email: C400-L-request-Zwy7GipZuJhWk0Htik3J/[email protected]
> 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-Zwy7GipZuJhWk0Htik3J/[email protected]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request-Zwy7GipZuJhWk0Htik3J/[email protected]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.