In dem folgenden Beispiel soll die Wirkung der Parameter erläutert werden. Es wird davon ausgegangen, dass auf einem Rechner eine UDS/SQL-Konfiguration als Hauptlast betrieben wird, für die bestimmte Systemleistungen garantiert werden sollen.
Das ideale Systemverhalten aus Sicht der Taskkommunikation ist, wenn sich einige Aufträge ansammeln, die dann die Servertasks unterbrechungsfrei abarbeiten. Parallel zur Abarbeitung können auch weitere Aufträge von anderen Prozessoren eintreffen, wenn weniger Servertasks vorhanden sind als Prozessoren.
Durch die richtige Einstellung der BS2000-Priorität kann dieser Effekt erreicht werden. Dabei wird ein BS2000-Schedulingprinzip ausgenutzt. Es wird nicht in jedem Fall eine höher priorisierte Task, die auf eine Prozessorzuteilung wartet, eine laufende, schwächer priorisierte verdrängen. Nur wenn der Prioritätsunterschied groß ist, wird dies geschehen.
Wenn die Anwendertasks eine geringfügig höhere Priorität als die Servertasks haben, werden zuerst viele Anwendertasks ihre Aufträge in den Auftragspool stellen, obwohl eine Servertask von der ersten Anwendertask bereits geweckt wurde. Die Servertask bekommt erst den Prozessor zugeteilt, wenn alle Anwendertasks im Warten auf die Auftragsbearbeitung sind.
Nun kommt die Servertask auf den Prozessor und arbeitet nacheinander alle anstehenden Aufträge ab, obwohl bereits nach dem ersten Auftrag die erste Anwendertask geweckt wird.
Dieser Effekt stellt sich aber nur bei Benutzung von festen Prioritäten sowohl für Server- als auch für Anwendertasks (im Bereich 127 bis 60) dauerhaft ein. Bei Verwendung von variablen Prioritäten (im Bereich 255 bis 128) werden die internen Prioritätswerte dynamisch vom Betriebssystem verändert, sodass das Echtzeitverhalten des Systems nicht mehr entsprechend vorhergesagt werden kann.
Bei Einstellung der BS2000-Priorität der Mastertask und dadurch der Servertasks von 120 (siehe RUN-PRIO bei ENTER-Jobs auf "DBH-Startkommandos") und der Anwendertasks von 119 ergibt sich auf einem Monoprozessor bei Ladeparametereinstellung PP SERVERTASK=1 folgende günstige Situation:
Auf einem Biprozessor mit der Ladeparametereinstelllung PP SERVERTASK=1 ergibt sich folgende günstige Situation, wenn der CPU-Anteil der Anwenderprogramme größer ist als der der Servertasks.
Auf einem Biprozessor mit der Ladeparametereinstellung PP SERVERTASK=2 ergibt sich folgende günstige Situation bei n Anwendern:
Damit auf dem Biprozessor mit zwei Servertasks eine ähnliche Situation entsteht wie bei nur einer Servertask, wenn der CPU-Anteil der Servertasks größer ist als der der Anwendertasks, sollte der Ladeparameter PP SCHEDULING=ASYMMETRIC eingestellt werden. In diesem Fall versucht eine Servertask kontinuerlich Aufträge zu bearbeiten; die zweite Servertask bearbeitet jedoch immer nur einen Auftrag.
Auf einem Quadroprozessor ergibt sich ein entsprechendes Bild wie auf dem Biprozessor mit mehr als einer Servertask.
Die Wirkung des Ladeparameters PP SCHEDULING=ASYMMETRIC ist damit die folgende: Dadurch, dass eine Servertask immer nur einen Auftrag ausführt, laufen alle anderen Servertasks auf den parallelen Prozessoren entsprechend länger.
Weitere Tasks mit niedrigerer BS2000-Priorität auf dem Rechner füllen die Prozessorzeit, wenn ein typischer, kurzzeitiger Lasteinbruch auftritt oder die Datenbankkonfiguration nur einen Teil der CPU-Zeit benötigt.
Weitere Tasks mit höherer BS2000-Priorität, wie z.B. Systemtasks, bringen die oben beschriebenen Abläufe nicht wesentlich aus dem Gleichgewicht, vorausgesetzt solche Tasks beanspruchen nicht einen Prozessor dauerhaft.