Nicole Willson wrote:
As far as I know the library was configured for zOS using sp6 code and that was simply adapted to sp7. I guess I don't know what you mean by configuring the library. I thought that was what I was doing by changing the rwc_std_11d.h file.
You can hardly expect to do it right just by tweaking the macros. There are dozens of them and many are #defined in response to very subtle conditions. In addition, there are many new tests in the latest version of the library that didn't exist back then. You need to compile, link and run the configuration tests to make sure the set is complete and their results make sense and are optimal. The library can adapt to a lot of bugs and limitations but the workarounds it uses aren't always as robust or as efficient as if the bugs didn't exist to begin with. For instance, the library might be able to adapt to the function wcslen() not being defined in the C library by defining its own simple loop. The C library version is almost always going to more efficient (typically written in assembly). An earlier version of an OS may not provide wcslen() but a newer might. Using a config header obtained on the older OS with the new one will work (if this were the only difference) but will cause the library to use the inefficient workaround when the more efficient libc function could be used instead. Anyway, this is just one of dozens of examples, and a pretty harmless one. I could easily come up with much more sinister cases. Suffice it to say that it's inappropriate and wrong (not to mention incredibly tedious) to try to port the library (any of our libraries, in fact, but stdcxx is likely to have the most serious problems) to a new compiler or OS by manually tweaking the autoconfiguration macros. Martin
