Bei einem Yield direkt unterhalb eines unterbrechbaren Bausteins kann nicht sichergestellt werden, ob der yieldende Baustein überhaupt in der Lage wäre, mit einer ggf. auftretenden Unterbrechung umzugehen1). In vielen Fällen ist es ja so, dass der yieldende Baustein sich für den Yield anstelle eines Unregisters nicht nur aus optischen Gründen entscheidet, sondern auch, um sich nicht erneut bei einer Datenbank anmelden zu müssen, irgendwelche Variablen oder Forms initialisieren zu müssen usw. Mit anderen Worten: der Baustein verlässt sich auf lokale Daten, die nicht als Bestandteil des Kontexts gespeichert werden. Die Frage, die geklärt werden muss, ist die, ob der Baustein sich wirklich gleich verhalten würde, wenn der Yield nicht mit Resume, sondern mit Cleanup beantwortet wird, und anschließend der Baustein erneut gestartet wird und einen „normalen“ Register macht.
Auch wenn die Anwendung so strukturiert wurde, dass eine Unterbrechung aus programmtechnischen Gründen zwischen Yield und Resume gar nicht erst passieren kann, ist dennoch von einer Unterbrechung auszugehen, falls z.B. das Netz ausfällt oder die Stromversorgung… Der gesicherte Kontext wird dann dazu führen, dass der Baustein neu gestartet wird, anstatt dass ein inaktiver Baustein mit einem Resume durchstarten kann.
Um das Verhalten im Falle einer tatsächlichen Unterbrechung feststellen zu können, ist eine Einstellung in der TAA\Config-Section der Registry möglich, und zwar GevoYieldIsCleanup als Binärwert der Länge 1. Wenn diese Einstellung den Wert 0 aufweist (Default), werden Yields in Bausteinen unterhalb eines unterbrechbaren Bausteins zugelassen. Wenn diese Einstellung jedoch den Wert 1 aufweist, werden Yields in einem solchen Fall mit Cleanup beantwortet, um testen zu können, ob der Ablauf auch mit einem Neustart des Bausteins funktioniert. In einem solchen Fall wird dies mit der Oops-Meldung „Caller is not on a technical control-flow level, and 'cleanup for yield' test-option has been selected.“ quittiert.