<snip> > 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. > > <unsnip>
Have you considered wrapping the native z/OS unicode conversion service with a thin assembler wrapper. This could then be used by your SPC program. You can either mimic the RTL interface with the wrapper or expose than functionality in a manner that best suits your needs. Sam ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
