When an LFN is reported as "fail" or "part" in the XML summary, it will be set as "problematic" in the TransformationDB.
Changes for MC productions:
The new MC jobs (so, not those that are NOW in the system, but those of the new productions that you will launch) will produce a non-fixed amount of events, but will work using the CPUTimeLeft of the queue, and the CPUNormalizationFactor of the CPU where they land.
There is anyway a hard limit, hardcoded, that no MC job will last more than ~24hours of real time.
When launching a new MC production, you will have to specify the CPUe (CPU time per event, in HS06s). I have seen that, for fast generations, it can be down to ~300 HS06s, but I suggest to be always a bit generous. This value can be calculated by simply doing CPUTimeOfEvent * CPUNormalizationFactor of the machine, where CPUTimeOfEvent is the real seconds it took generating an event on the test machine. An MC testing machinery will come, but since it has not been yet developed,
In the template of MC prods, you won't find any more the MaxCPUTime (for which you usually put 700000 HS06s, I think), but a minimum value. The default is 50000 HS06s, which seems reasonable. This way, almost any queue will match a MC job, just they will produce less events
You won't need to specify the number of jobs to create, this will be done automatically
You won't need to extend the MC prod, again this will be done automatically by a new agent, the MCExtensionAgent, when the MC production is Idle, that will pick info from the ProductionRequest page.
You won't need to specify the SystemConfig, because, as said above, for new steps it is now a parameter of the steps, not of the productions. For productions that use steps already in the system, or new steps that don't specify the SystemConfig, the default will be set to "x86_64-slc5-gcc46-opt".