---

Hallo,
ich habe eine Frage zu der Anwendung der Funktion CallOperators/des Atomes Team.

Ich habe einen Server, dieser soll, je nach eintretenden Produkt, unterschiedliche Operatoren,
die aus unterschiedlichen Teams kommen, anfordern. Die Produkte können bspw. den Namen "blau" tragen.
Die Teams haben die Namen "P", "A", "S".
Dem Server ordne ich bei "Trigger on Entry" folgende IF-Anweisung zu:

if (=(CompareText(Name(i), [blau]), 1),
  CallOperators(AtomByName([P], Model), 1, [I]),
  Do(CallOperators(AtomByName([A], Model), 1),
      CallOperators(AtomByName([S], Model), 1)))

Diese IF-Anweisung wird ohne Probleme ausgeführt. D.h. es werden (entweder 1 oder) 2 Operatoren von unterschiedlichen
Teams gerufen. Danach passiert aber leider nichts mehr. D.h. das Produkt wird nicht weitergegeben an das danach folgende Atom.
Die "Trigger on Exit" Anweisung des Servers wird definitiv nicht ausgeführt.
Wenn ich keine Do-Anweisung verwende, wird das Produkt weitergegeben, die "Trigger on Exit" Anweisung ausgeführt.
Ich schlussfolgere daraus, dass die Verwendung von CallOperators()
innerhalb einer Do-Anweisung zu dem Fehler führt. Warum?
Wie kann man sonst noch auf Operatoren von unterschiedlichen Teams zugreifen, dabei aber keine Do-Anweisung verwenden?

Danke für euere Hilfe,
Katjes

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo katjes,

hier liegt meiner Meinung nach eine Schwäche in der
Funktionsweise des Call-Operator-Befehls vor.

Das ganze funktioniert so, dass bei jedem Call Operators alle Events
vom Rufer (in Ihrem Fall der Server) in die Zukunft verlegt werden,
so dass alle Aktionen ruhen, solange bis alle gerufenen Operator
gekommen sind. Das macht Sinn, denn erst wenn alle da sind, soll
die Bearbeitung starten.

Der Delay-Befehl steht im Event 1 des Teams:

    "{* 1: Set calling atom on hold *}
    Do(
      Status( i) := 30,      {* Waiting for Operator *}
      DelayEvents( 1000000000000, i)
    )"

Sind alle gerufenen Operator da, so werden die Events
des Servers aus der Zukunft zurückgeholt, und die
Bearbeitung beginnt. Siehe Event 3 des Operators:

    "If(Label( [t-opnumber], cs) = 0,"

ein Stück weiter unten:

    "DelayEvents( Time - Label( [t-calltime], c) - 1000000000000,cs)"

Und hier liegt die Ursache dafür, dass der Server in Ihrem
Fall nicht weiter arbeitet, sobald alle Operator da sind.
Denn durch den 2maligen CallOperator wurden die Events
des Servers um 2 x 1000000000000 Sekunden in die Zukunft versetzt,
jedoch findet das Zurückholen nur 1 mal statt, weil die
gerufenen Operators bei Ankunft am Server nicht unterscheiden
zu welchem Team sie gehören. Nur der letzte erkennt anhand von
"Label( [t-opnumber], cs) = 0" dass es weiter gehen darf,
und holt die Events einmalig aus der Zukunft zurück.
Es bleibt ein Versatz von 1000000000000 Sekunden übrig,
der dafür sorgt, dass der Server nie die Bearbeitung startet.

Lösungsansatz:

Die Operators müssen beim Eintreffen erkennen, zu welchem Team
sie gehören. Für jedes Team muss es einen eigenen Zähler für die
gerufenen Mitarbeiter geben, so dass jedes Team für sich bei
Ankuft des letzten Teammitgliedes die Events aus der Zukunft
zurück holt.

Alternativ:

Ein Merker an den Server, der verhindert, dass die Events mehrfach
in die Zukunft verschoben werden.

Hoffe das hilft.

Grüße

EnterpriseDynamics

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo noch mal,

erstmal DANKE an "Enterprise Dynamics" für Ihre Hilfe.
Ich habe mich für die Variante mit dem Merker entschieden - bis jetzt funktioniert es:-).

Jetzt ist aber ein anderes Problem aufgetaucht:
Ausgangslage:
- EIN Team;
- Wenn ich die Operatoren erst beim Eintreffen eines Produktes in den Server rufe, kann es vorkommen,
dass der Server bereits durch ein Produkt belegt ist, aber die für dieses Produkt zur Bearbeitung notwendigen Operatoren noch gar nicht da sind.
Dadurch wird der Server für andere Produkte blockiert, was aber in meinem Fall nicht sein darf.

Lösungsideen:
Deshalb wollte ich die Operatoren bereits beim Austreten aus der Warteschlange rufen. Dieses Vorgehen ist aber fehleranfällig, wenn die Warteschlangenkapazität größer als eins ist,
und somit auch zu einem bestimmten Zeitpunkt mehr als ein Produkt in der Warteschlange wartet.

Aus diesem Grunde wollte ich jetzt vor dem Eintreffen des Produktes in den Server prüfen, ob die benötigten Operatoren für das jeweilige Produkt zur Verfügung stehen. Wenn ja, dann tritt das Produkt in den Server ein. Wenn nein, wartet das Produkt weiterhin in der Warteschlange.
Mit dieser Idee sind dann die folgenden Fragen aufgetreten:
- Wie kann man generell auf einen Operator zugreifen? Nach meinen Versuchen jedenfalls nicht durch den 1. Ausgangskanal eines Teams, oder?
- Welche Status kann ein Team bzw. ein Operator annehmen?
- Hat ein Team wirklich nur ein Label? (t-opnumber)?
- Ist es möglich, pro Team die Information zu erhalten welche Operatoren zum Team gehören  und ob diese Operatoren gerade frei sind, oder nicht?
- Ich hatte mir überlegt mit Hilfe von  OnICReady (vom Server aus gesehen) bzw. mit OnOcReady (von der Warteschlange aus gesehen) die Abfrage durchzuführen, also ob für ein Produkt die benötigten Operatoren frei sind, oder nicht – Gibt es dafür auch noch eine andere Möglichkeit?

Würde mich freuen, wenn mir wieder jemand weiterhelfen könnte. DANKESCHÖN!

Katjes

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo katjes,

nachfolgend der Versuch alle Fragen zu beantworten.

Zu 1.
Die Operator werden durch den "Call Operator" Befehl mit dem Atom
verbunden, das sie gerufen hat. Leider sind diese Kanäle ausgeblendet,
sie lassen sich jedoch im AtomEditor einblenden, indem im Folder "2D"
der Haken aus "Hide Channels" genommen wird. Sind die Channels erst
mal sichtbar, dann lässt sich die Channelnummer feststellen, über
welche referenziert werden kann.

Zu 2.
Das Team-Atom selbst hat keine saubere Statusverwaltung, macht auch
keinen Sinn, weil ja die angeschlossenen Arbeiter unterschiedliche
Zustände haben können.
Was die Arbeiter selbst betrifft, so konnte ich folgende Stati finden:
1  (idle)                wird OnReset gesetzt
33 (travel to job)        wird an alle gerufenen Operator vergeben
30 (waiting for Operator) kriegen Operator die auf weitere Kollegen
                          warten, falls ein Arbeiter nicht reicht.
Das Atom, das den "Call Operator" Befehl abgeschickt hat bekommt
übrigens auch den Status 30 (waiting for Operator) verpasst, solange
bis alle gerufenen Operators angekommen sind (siehe Event 1 im Team):

{* 1: Set calling atom on hold *}
Do(
  Status( i) := 30,      {* Waiting for Operator *}
  DelayEvents( 1000000000000, i)
)

Zu 3.
Das Label "t-opnumber" ist nicht dem Team-Atom zugeordnet, sondern
jenem Atom, das den "Call Operator" Befehl abgeschickt hat. Es gibt
meiner Meinung nach nur 1 Label. Das war ja auch der Grund für die
Schwierigkeiten beim Rufen von Operatoren aus 2 verschiedenen Teams.

Zu 4.
Über den Status der Operatoren (1)Idle oder nicht Idle geht das.
Alle Operatoren die zu einem Team gehören sind ja mit dem Team
über Channels verbunden, diese sind nur ausgeblendet (siehe Zu 1.).

Zu 5.
Wenn ich die Aufgabenstellung richtig verstanden habe, dann soll
die Bearbeitung von mehreren Produkten gleichzeitig in einem Server erfolgen.
Das ist Meiner Meinung nach nicht ganz so easy zu handeln.
Folgender Alternativvorschlag:
Der Ruf wird momentan vom Server OnEntered abgeschickt, richtig?
Wenn dem so ist, dann stellt sich grundsätzlich die Frage,
ob es richtig ist, hier den Server zu verwenden.
Ich denke es wäre hier günstiger das Multiserver-Atom zu nehmen.
Der Multi-Server ist standardmäßig für die gleichzeitige Bearbeitung
mehrerer Produkte ausgelegt und bietet sich deshalb an.
Der Ruf sollte sich jedoch nicht auf den Multi-Server selbst
beziehen, sondern auf das Produkt, das bearbeitet werden soll.
Dadurch werden die Operators an das Produkt gebunden und nicht
an die Maschine. Das hat zum einen den Vorteil, dass jedes
Produkt ein eigenes Label "t-opnumber" haben kann, das die gerufenen
Operator richtig runterzählt, weiterhin werden die Events nicht für
die Maschine "delayed", sondern für die Produkte, so dass auch hier
keine Fehler mehr passieren können. Somit ist die Maschine nicht
mehr in das ganze Operator-Gerufe involviert und es kann zu keinen
Überschneidungen mehr kommen.

Folgendes wäre zu machen:

OnEntered im Multiserver ruft der Multiserver nicht mehr für sich
selbst sondern das Produkt (i) muß den Call-Befehl abgeben. Dadurch
werden die Operator an das Produkt gebunden.
(Entrytrigger im Multiserver):

      do(
      SetRank(1,i),  {--notwendig, weil der Call-Befehl auf das First(c) geht--}
      CallOperators(AtomByName([Team1],Model), 1)
      )

Der Code im Multiserver muß geändert werden, damit der Entritrigger
erst nach dem Event ausgeführt wird. Weiterhin wird der Event 1 zum
Produkt umgeleitet.
(OnEntered vom Multiserver):

      do(
      closeallic(c),
      setstatus(if(=(att(4,c),0),2,25),c),
      setatt(3,att(2,c),c),
      sddb([t-cycle],att(3,c),i),
      createevent(att(3,c),i,1,0,i),    {--Ruf umleiten zum Produkt--}
      att(7,c),                                {--führt den Entrytrigger aus, in dem der Call-Befehl steht--}
      createevent(0,c,2)
      )

Hierzu am besten eine Kopie vom orginal Multiserver als neues
Bibliothekselemet anlegen.

Das Produkt muß den umgeleiteten Event wieder an den Multiserver
zurückgeben, sobald die Bearbeitungszeit abgelaufen ist.
(OnEvent vom Produkt):

  CreateEvent(0,Up(c),1,0,i)    {--Bearbeitungszeit beendet, Produkt weiterleiten--}

Ich hoffe das hilft weiter.

Grüße
EnterpriseDynamics

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Nachtrag:

Event 1 vom Team muss auch noch geändert werden
(neues Bibliothekselement anlegen).

{* 1: Set calling atom on hold *}
Do(
  Status( First(i)) := 30,      {* Waiting for Operator *}
  DelayEvents( 1000000000000, first(i)  {--First(i) ist das Produkt--}
),

Dadurch werden die Events vom Produkt verschoben und nicht mehr die
vom Multiserver.

Gruß
EnterpriseDynamics

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,

Ja, es hilft mir weiter :-)
ich Danke „EnterpriseDynamics“ erneut für die Klärung meiner Fragen.
Die Kommentare zu meinen Fragen 1-4 kann ich nachvollziehen.
Zur Frage 5 muss ich die Aufgabenstellung richtig stellen (meine vorige Erklärung war da wohl zu ungenau – Entschuldigung!):

Ausgangssituation:
Eine Warteschlange -> ein Server

In einer Warteschlange befinden sich Produkte. Ein Produkt dieser Warteschlange soll die Warteschlange nur verlassen können, wenn der benötigte Operator (bzw. mehrere Operators) und der benötigte Server frei sind. Nur in diesem Falle soll das Produkt die Warteschlange verlassen können. Das Produkt wird sozusagen von dem Operator abgeholt und zum freien Server begleitet.

Meine Überlegung war, dass vor dem Austreten eines Produktes aus der Warteschlange die Operators gerufen werden, sind diese dann da, verlässt das Produkt die Warteschlange und tritt in den Server ein.
Bei der Verwendung von CallOperators() hatte ich dann aber das Problem, das der Operator nicht, dem die Warteschlange verlassenden, Produkt zugeordnet wird, sondern der Warteschlange an sich. Deshalb hatte ich dann wieder überlegt, dass ich das ganze Problem mit Abfragen von der Serverseite her gesehen angehe.

Ich denke, dass mir da einige Ansätze aus der Erklärung von „EnterpriseDynamics“ zu Frage 5 weiterhelfen werden.
Annahme meinerseits zur Erklärung der Frage 5 von „EnterpriseDynamics“: Mit „Multi-Server“- Atom ist das „Multi-Service“ Atom gemeint, oder?

Bis Bald
Katjes

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP