Bug 108171

Fixed in p4 37482

I've just learned of the existance of  'MasterTool' which apparently obsoletes
PackageTool & ConfigTool, so this fix will have to be repeated for this new tool.

done

This fails even simple testing:

[arturo@staging01 aplaws-camden]$ ccm load ccm-core
 *** Error ***
Parameter waf.runtime.jdbc_url has the following errors:
        The value must not be null
Parameter waf.web.server has the following errors:
        The value must not be null
Parameter waf.admin.email has the following errors:
        The value must not be null
Parameter waf.admin.name.given has the following errors:
        The value must not be null
Parameter waf.admin.name.family has the following errors:
        The value must not be null
Parameter waf.admin.password has the following errors:
        The value must not be null
Parameter waf.admin.password.question has the following errors:
        The value must not be null
Parameter waf.admin.password.answer has the following errors:
        The value must not be null
[arturo@staging01 aplaws-camden]$ 
[arturo@staging01 aplaws-camden]$ echo $?
0
[arturo@staging01 aplaws-camden]$ 

Interestingly enough this passes slightly more complicated testing. If
you invoke MasterTool either directly or using older versions of the
ccm script it does in fact produce the correct exit status. This leads
me to believe that the exit status is not being properly propogated by
either the ccm-run or ccm wrapper scripts. I'd suggest having Dennis
take a look.

After a bit more investigation I think I know what the problem is.
Both ccm-run and ccm use the following perl idiom to invoke subprocesses:

system "foo";
exit $?

This is problematic because $? doesn't actually contain the error code
from the subprocess, it contains some munged value. The lower 8 bits
are set to indicate that the subprocess died from a signal or
something like that, in any case you need to divide $? by 256 in order
to get the actual exit status of the subprocess. Alternatively a
better way might simply be to use the 'exec("foo") or die' idiom.

The reason the exit status is being reported as 0 in this case is
because the subprocess correctly dies with an exit code of 1 and $? is
set to 256, and apparently exit $? simply ignores the high bits
resulting in an exit status of 0.

thanks for tracking this down.  fixes checked in at 38232

Still a problem. 
[jorris@localhost cms]$ ccm load ccm-core
 *** Error ***
Parameter waf.admin.email has the following errors:
        The value must not be null
Parameter waf.admin.name.given has the following errors:
        The value must not be null
Parameter waf.admin.name.family has the following errors:
        The value must not be null
Parameter waf.admin.password has the following errors:
        The value must not be null
Parameter waf.admin.password.question has the following errors:
        The value must not be null
Parameter waf.admin.password.answer has the following errors:
        The value must not be null
[jorris@localhost cms]$ echo $?
0

Marking QA Fails, just so it's obvious.

I can't reproduce, nor can dennis & dan. 
Tis must've been fixed. Perhaps I had an out of date dev environment.