CRPence | 10 May 2013 15:51
Picon
Favicon

Re: AS400 C++ calling COBOL - MCH0802

   The Opening Post provided a complete CBLLE source for the "CALLEE" 
[and two sources for the CALLER; one is CBLLE] for which the compiled 
*PGM object as created with the Create Bound COBOL Program (CRTBNDCBL) 
command effects min=0\max=3 for the "Number of parameters".  A snippet 
of that complete CBLLE source, for which apparently the "USING" effects 
the explicitly defined /hard/ number of parameters rather than a more 
/theoretical/ or /soft/ limit for the maximum, is included here:

        ------- CALLEE.CBL --------
        ...
        LINKAGE SECTION.
        01 P1 PIC X(5).
        01 P2 PIC X(5).
        01 P3 PIC X(5).
        PROCEDURE DIVISION USING P1 P2 P3.
        ...

Regards, Chuck

On 09 May 2013 23:32, Jevgeni Astanovski wrote:
> are you sure that minimum number of parameters and maximum number of
> parameters returned by QCLRPGMI are somehow "related to reality"?
>
> I just had a look at ILE/RPG programs (attribute RPGLE). They all
> (OK,  all that I looked at) have the following:
>
> Program statistics:
>    Number of parameters . . . . . . . . . . . . . :   0        255
>
> And this is for a program, that I know, needs exactly 5 parameters.
(Continue reading)

Sergey Kashyrin | 9 May 2013 19:59
Favicon

Re: AS400 C++ calling COBOL - MCH0802

Hi Chuck,

>   I am obviously unaware of the details... But IMO a more obvious 
> resolution to avoid any logic in the CALLER, would be to code the CALLEE 
> to accept the additional two parameters regardless they are unused.

It is not possible in my case. I have 1 caller and more than 3000 of callee-s
Caller let say have "all information", and "callees" accepting only what they want.
And of course all of that is dynamic, so I don't know who I will call next.
To rewrite 3000+ COBOL programs could require a good budget :-)

Thanks,
Sergey

--

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

CRPence | 9 May 2013 01:49
Picon
Favicon

Re: AS400 C++ calling COBOL - MCH0802

On 08 May 2013 11:44, Sergey Kashyrin wrote:
>
> Thanks, I've also figured out that my test is incorrect - just
> messed playing with 3-5 parms on many platforms, so I'm getting MCH
> on COBOL call COBOL also if I use 5 parms.
> For now I see the only way to avoid this issue (which does not exist
> on the platforms other than AS400) is to do the call to
>
> QCLRPGMI(&info, ...
> and figure out the expected number of parameters
> (info.Max_Parameters) and then code a huge switch with calls :-)))

   I am obviously unaware of the details... But IMO a more obvious 
resolution to avoid any logic in the CALLER, would be to code the CALLEE 
to accept the additional two parameters regardless they are unused.

   Of course I generally prefer having the caller use a distinct 
invocation for each different parameter-style, so which type of 
invocation has failed is very conspicuous; i.e. if there is just one 
generic CALL PGMX (&Addr_of_Parm_List), then every variation of the CALL 
that fails on the same HLL statement, and therefore only by debug or 
good logging will I learn which variation of the invocation had been 
established.

-- 
Regards, Chuck
--

-- 
This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L) mailing list
To post a message email: C400-L@...
To subscribe, unsubscribe, or change list options,
(Continue reading)

Sergey Kashyrin | 8 May 2013 20:44
Favicon

Re: AS400 C++ calling COBOL - MCH0802


Hi Chuck,

>   The example given shows the CALL passing *three* parameters, not 
> five; i.e. per the USING:
>       CALL SUB USING P1 P2 P3.

Thanks, I've also figured out that my test is incorrect - just messed playing with 3-5 parms on many platforms,
so I'm getting MCH on COBOL call COBOL also if I use 5 parms.
For now I see the only way to avoid this issue (which does not exist on the platforms other than AS400) is to do
the call to

QCLRPGMI(&info, ...
and figure out the expected number of parameters (info.Max_Parameters) 
and than code a huge switch with calls :-)))

Regards,
Sergey

--

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

CRPence | 8 May 2013 04:05
Picon
Favicon

Re: AS400 C++ calling COBOL - MCH0802

On 07 May 2013 15:56, Sergey Kashyrin wrote:
>
> 1. I have ILE COBOL program (*PGM) with let say 3 parameter

   The source shown will be created with *three* parameters for which 
its compiled program object will accept a minimum of zero parameters and 
a maximum of three parameters; i.e. per the declarative:
       PROCEDURE DIVISION USING P1 P2 P3.

> 2. I am calling this program (dynamically) from other COBOL program let say
> with 5 parameters - call is going thru, everything is okay.

   The example given shows the CALL passing *three* parameters, not 
five; i.e. per the USING:
       CALL SUB USING P1 P2 P3.

> 3. I need to do the same call from C++ - I am getting MCH0802 (number of
> parameters mismatch).

   That call is coded to pass *five* parameters; i.e. P1 to P5 are the 
arguments passed on the function invoked by address:
       os_fct_ptr(p1, p2, p3, p4, p5);

   The MCH0802 for its second level text apparently read: "Program 
CALLER attempted to call program CALLEE with 5 parameters. Program 
CALLEE expects a minimum of 0 and a maximum of 3 parameters."

   Had the following call been coded within the program CBCALLER, to 
truly pass *five* parameters, then that invocation would have effected 
the same MCH0802 [of course with the proper name appearing for the 
(Continue reading)

Sergey Kashyrin | 8 May 2013 00:56
Favicon

AS400 C++ calling COBOL - MCH0802

Good day,

Here is the problem:

1. I have ILE COBOL program (*PGM) with let say 3 parameter
2. I am calling this program (dynamically) from other COBOL program let say
with 5 parameters - call is going thru, everything is okay.
3. I need to do the same call from C++  - I am getting MCH0802 (number of
parameters mismatch).

What is wrong and how to avoid that ?

Regards,
Sergey

-------------- CALLEE.CBL ------------
        IDENTIFICATION DIVISION.
        PROGRAM-ID. CALLEE.
        ENVIRONMENT DIVISION.
        DATA DIVISION.
        WORKING-STORAGE SECTION.
        LINKAGE SECTION.
        01 P1 PIC X(5).
        01 P2 PIC X(5).
        01 P3 PIC X(5).
        PROCEDURE DIVISION USING P1 P2 P3.
        0000-MAIN.
            DISPLAY 'P1=' P1 ';'.
            DISPLAY 'P2=' P2 ';'.
            DISPLAY 'P3=' P3 ';'.
(Continue reading)

CRPence | 18 Feb 2013 01:46
Picon
Favicon

Re: QXXPTOD API from an ILE CL program

   I agree with the situation about those having only CL available [I 
have even been in situations where that was the effective scenario], and 
that the value in knowing how to do the work in CL irrespective of its 
potential usefulness generally... because they are educational.

   I just want to clarify however, that the OP noted [and to what and 
why I responded was] that the issue involved an educational example of 
ILE CL calling a procedure with CALLPRC; i.e. for a "presentation" that 
was being prepared.  I was of the opinion that FLOAT was an unnecessary 
complexity which could easily be avoided; i.e. there was no reason to 
use that "rather complicated sample as a good representation of what ILE 
is", when so many other examples could be had without needing to pass a 
FLOAT data type.  And FWiW the "system I have used lately", although 
left unmentioned, is one which has no access fees and also gives free 
access to an RPG compiler.  Thus I could have created the module, saved 
the object, and transported the object anywhere required.  About the 
only limitation for the person with only CL available, is if that person 
has the ability to RSTOBJ... because we can probably safely assume they 
can CRTPGM.

Regards, Chuck

On 17 Feb 2013 13:35, Bruce Vining wrote:
> <<SNIP>> I have also met quite a few developers who only have CL
> available to them. So documenting how to do it in CL, even though I
> would most likely call some RPG or C code if doing it myself, is
> certainly a worthwhile discussion. Doing it in another ILE language
> just isn't an option for some users.
>
>> On Sun, Feb 17, 2013 at 12:09 PM, CRPence wrote:
(Continue reading)

CRPence | 17 Feb 2013 21:09
Picon
Favicon

Re: QXXPTOD API from an ILE CL program

On 17 Feb 2013 06:13, paul.roy@... wrote:
> My today concern is that I am preparing a ILE CL presentation and I
> am not sure that I will present this rather complicated sample as a
> good representation of what ILE is.
> hopefully I have other example using IFS or HTTP API's...
> I am still dreaming of future CL enhancement with *FLOAT data
> type...
>
>               pgm
>               DCL        VAR(&A) TYPE(*FLOAT) LEN(8) value(300)
>               DCL        VAR(&B) TYPE(*FLOAT) LEN(8) VALUE(400)
>               DCL        VAR(&C) TYPE(*FLOAT) LEN(8) value(0)
>               CALLPRC    PRC('hypot') PARM(&A &B) RTNVAL(&C)
>               endpgm
>
> would it not be simple, nice, easier, more readable ?

   Certainly that would be all those things.  However at some point the 
question becomes... Why must the ILE variant of the Control Language 
need to do everything that the other ILE HLLs can do?

   One can just choose to write in another ILE Language to make either a 
wrapper of the 'hypot' routine or write the code to perform the work of 
the 'hypot' routine.  The system I have used lately, does not even have 
the C++ routines, so I would not even have the option to call them from 
_any_ language; creating a wrapper is not even an option.  There is 
little reason an example for educational purposes should have to use 
FLOAT.  Just call a routine to do the Square Root in any language that 
has that instruction\operator, plus the capability to accept the Packed 
Decimal as input; the RPG has /native/ handling for Packed Decimal and 
(Continue reading)

Jevgeni Astanovski | 15 Feb 2013 10:07
Picon
Favicon

Creating temporary table

Hello,

Such a trivial operation and I understood that I do not see simple solution...
A program needs to use a temporary table, I assumed that QTEMP is the best place for it.
So I have a table with the same structure in MYLIB and program needs to create its copy, however, empty, and in QTEMP.

I shall issue a CL command CRTDUPOBJ from my C program, but I cannot gurantee, that the table does not exist
there already.
I see two ways to protect myself from this situation:

1.      Capture relevant error message (probably CPD2104, object already exist);

2.      Issue unlink (Unix style API) to delete this file before making CRTDUPOBJ - but this will end in error if
file does not exist.

Or I should rather attempt to open file using _Ropen with mode "wr" and if it ends in error, issue CRTDUPOBJ
and make _Ropen again?

All these methods seem odd - that made me think that maybe there is some better way...

Thanks,

Jevgeni

--

-- 
This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L) mailing list
To post a message email: C400-L@...
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@...
(Continue reading)

Barbara Morris | 15 Feb 2013 01:35
Picon

Re: QXXPTOD API from an ILE CL program

On 2/14/2013 4:14 PM, Jon Paris wrote:
>
> Barbara Morris might have more to add to this - she was the person I
> worked with on this issue - but I do remember I wasted a lot of time
> trying to get it to work before the guys in Rochester told us we were
> wasting our time.
>

I remember our discussions on this Jon. I don't really have anything to 
add though. The issue is as you said - character (or more generally 
"aggregate") values are passed using a different mechanism from scalar 
types like float and integer. (The fact that RPG considers character 
strings to be scalar is irrelevant to the optimizing translator.)

-- 
Barbara
--

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

Jon Paris | 14 Feb 2013 22:14

Re: QXXPTOD API from an ILE CL program


On Thu, 14 Feb 2013 at 13:59:36, paul.roy@... wrote:

> Hello, 
> 
> I would like to use C math functions in a CL program... but most of those 
> functions use doubles.. which are not supported in ILE CL... 

I don't think you will ever get it to work. I'm having to dig deep into my memory banks of this but if I recall
correctly ...

I experimented with trying to do this with RPG back in the V3R6 time frame. i.e. Faking out doubles by using a
char field. The problem is that apparently the way the system passes doubles under the covers is not the
same as it passes char. As a result while you can get the right value set in the char field that is not what the
API will see. I can't remember the gory details and it probably does't matter - but you might have noticed
that in the next release of RPG, floats were added to the language. Hmmmm - wonder why that was?

Barbara Morris might have more to add to this - she was the person I worked with on this issue - but I do remember
I wasted a lot of time trying to get it to work before the guys in Rochester told us we were wasting our time.

Jon Paris

www.partner400.com
www.SystemiDeveloper.com

--

-- 
This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L) mailing list
To post a message email: C400-L@...
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
(Continue reading)


Gmane