Hello David,
the two mallocs are in different load modules.
The SPC malloc is in the load module that we build,
that is, the MQS exit. The SPC malloc is statically linked
to the MQS exit. The SPC philosophy is: link everything statically
to the requesting load module, so that there is no LE runtime environment
needed.
But the (legacy) MQS exit also contains a call to iconv, and iconv is
not part of the SPC library. iconv is resolved by a stub (only 10 bytes),
which calls the LE runtime DYNAMICALLY. This is another load module,
called CEESG003, and there is the RTL malloc, which is called by iconv.
The error is, in my opinion, that programs using the SPC library should
not use other functions from the "normal" RTL library than the ANSI C
functions
like fputs, fgets, the string functions and so on, which are designed in
such a
way that they don't need other functions from the "normal" RTL which
conflict
with the SPC functions. But iconv uses malloc, and this conflicts with the
SPC malloc.
I'm not 100 percent sure about this, but this is what I see in the
dumps. I looked
at the save area traces and saw a 0C4 below iconv - malloc - $$XMGET etc.,
and this was not the malloc from the SPC, but the address range showed that
it was the malloc from CEESG003 (same address range as iconv). I guess that
$$XMGET looked for the heap control blocks of the LE runtime and
couldn't fnd
them (they must be anchored from the CEECAA, register 12, IMHO).
Kind regards
Bernd
Am 04.06.2011 03:40, schrieb David Crayford:
On 3/06/2011 9:20 PM, Bernd Oppolzer wrote:
Hello David,
yes, we are using EDCXSTRL. But anyway:
iconv is part of the RTL runtime package, this is a large module
called CEESG003. Part of this module is the RTL malloc routine, too.
The references between the two are already resolved, so the RTL iconv
will always call the RTL malloc.
In the MQS exit, we have calls to iconv and malloc, among others.
These two
external references are resolved in the following ways: the iconv
that we
call is resolved by a stub which calls the iconv part of the RTL runtime
package dynamically which in turn calls the RTL malloc. The malloc that
we call is resolved by the SPC malloc.
But that's what I don't understand Bernd. How can there be multple
malloc's in the same load module. Even if one
is just a stub. If you link in the following order then the SPC
version of malloc should be the only malloc!
//SYSLIB DD DSN=SYS1.CEE.SCEESPC,DISP=SHR
// DD DSN=SYS1.CEE.SCEELKED,DISP=SHR
So we have a mixture of two different mallocs. The mallocs that we do
outside
iconv are resolved by SPC malloc, and the malloc inside iconv stays
with the
RTL malloc (because the RTL runtime package is not relinked again;
the linkage
between RTL iconv and RTL malloc is fixed in the CEESG003 load module
and
does not change).
Kind regards
Bernd
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
