Re: QLGCNVCS problems with V5R3 -- MIDRANGE-L

Peter

I hope to believe that this is a common error - at least the 2 of us have made a similar mistake in the past, and 2 is more common than 1, eh?

The issue is that everything in CL (before V5R3) uses pointers for passing parameters. Many of the APIs want you to send them an integer, say, as in this case, and have it sent as the real value, not as a pointer to the value. That means you cannot use this API safely in CL before V5R3. If I read the docs right, you are actually sending the first 4 bytes of a pointer.

The thing to watch for in the API doc is for an asterisk in parentheses, as in char(*) - this means a pointer to characters. If it says long or int, that is not a pointer. If you look at the member QLGCNVCS in QSYSINC/H you will see

void QLGCNVCS(char *,
              char *,
              char *,
              long,
              char *);

Note that there is no * after the word "long", so it is not a pointer.

Scott Klement helped me with this some time ago.

You could see what is happening in debug with your own program - can't debug IBM's stuff. Write a little RPGLE module with a single parameter with the VALUE keyword - you'll need to use a prototype and procedure interface combination, not a *PLIST. Then call it with a CLLE module, passing the *DEC variable. When I did this, the integer in the RPG module had the value x'520019FF' (1375738367).

My CLLE is

pgm
dcl &badint *dec (4 0) 234
callprc testptr &badint
endpgm

My RPGLE is

h nomain

dtestptr          pr
d                               10i 0 value

ptestptr          b                   export

dtestptr          pi
d intbyvalue                    10i 0 value

d moveto          s             10i 0

 /free
  moveto = intbyvalue;
 /end-free

ptestptr          e

Compile each with DBGVIEW(*ALL), then CRTPGM with the CLLE first in order. STRDBG, set a breakpoint on the assignment statement in the RPGLE, run it and see what the value is coming in.

HTH
Vern

At 11:42 AM 5/17/2005, you wrote:

"The &LENGTH parameter in this program is defined as *DEC but the API is
expecting *INT.  The statement

DCL        VAR(&LENGTH) TYPE(*DEC) LEN(4) VALUE(50)

is creating &LENGTH with a value of x'0000050F' which the API is
interpreting as 1295 - just a bit longer than the 50 bytes you are really
passing.  On V5R3 you could change to

DCL VAR(&LENGTH) TYPE(*INT) VALUE(50)

which would give you x'00000032' (a length of 50).  Alternatively you
could

DCL VAR(&LENGTH) TYPE (*CHAR) LEN(4) VALUE(x'00000032')

Your API call may have appeared to be working OK on prior releases, but
you
were inadvertently corrupting storage which may have caused other
application functions to work "strangely"."

Thank you Bruce for pin-pointing the error and for your advise on this
issue.  This is oficially the first API I work with and they are tricky
when you do not know them too much :o)

Thanks again!


Peter Vidal
PALL Corporation / SR Programmer Analyst, IT Development Group
10540 Ridge Rd., Ste 203, New Port Richey, FL 34654-5111
http://www.pall.com

"Courage is the strength or choice to begin a change. Determination is the
persistence to continue in that change."
-- Anonymous --
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.