Man, That would be a bad day...I seen a comma in a sysgen drive people nuts, of ourselves everyone was under the gun..
Scott ford www.identityforge.com On Sep 5, 2012, at 5:34 PM, Bernd Oppolzer <bernd.oppol...@t-online.de> wrote: > I got answers like this, before. > > These things work well, if you are in a development environment > or in an earlier test stage. > > What we have: we have a production system or an "almost" production system > in a very late stage. Then, when combining severel hundred PL/1 modules and > DLLs and several hundred C++ and C DLLs (written by several hundred different > people), we suddenly discover that our service regions start to request more > and more storage during the day shift ... > > Ok, while writing this, I see the point ... our legacy C modules are well > tested, > because we have tools that support testing of components, and those tools > even check for storage leaks etc. And for the C++ components in the new > system, > we don't have such support - it's not our fault; management believed that such > tools are not needed and only recently (after 5 years) spended some money to > improve the development and testing process. So the C++ components are > not well tested and the problems arise in a very late stage ... > > another part of the problem is that there is not enough time to do component > tests and that many of the co-workers are not accustomed to do this - > they throw the whole thing together and start testing it as a whole - > which will not work, if you have such a large system. > > The storage leak is only one small part of the problem ... > > C++ as another player in this context makes things worse, not better. > When we have to examine the behaviour of the overall system, the effects > of the C++ runtime is sometimes like a mystery for us. > > Very interesting effects can also occur, if a PL/1 ON ERROR unit tries > to continue on short-on-storage-conditions, which occur in C or C++ modules > ... > especially if this error-handler decides to provide only minimal dump > information ... > with some 100 modules in your address space, it will take you days to find > the error ... > > Kind regards > > Bernd > > > > Am 05.09.2012 19:47, schrieb Charles Mills: >> In many C++ implementations it is possible to replace 'new' with your own >> 'debug_new' via a macro, and trace or link all of the "malloc's.". >> >> Both of the C++ environments that I use (IBM z/OS XLC and MS VS) have >> built-in "find the leak" functions that I use routinely to make certain I am >> not leaking storage. >> >> Charles >> >> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
