-
Hallo
das mit aloc versteh ich nicht.
wenn job-a den aloc setzt, kann job-a doch kein 2. mal laufen
oder ?
Leider werden diese jobs gekillt ohne aufzuräumen.
Das ist eine vorrangsautomatik die sehr komplex ist. Und bisher auch problemlos.
DiBe
-
Ja stimmt, du hast Recht. Ein ALCOBJ hilft da nicht.
Da ja der Job selber durchaus mehrmals laufen darf.
Die Killproblematik ist da natürlich nicht zu verachten.
Es bleibt dir nur die DTAARA-Variante als Zähler:
JOBADTA
JOBBDTA
Job-A prüft, ob JOBBDTA > 0
Wenn ja -> Warten oder Ende ?
Wenn Nein -> JOBADTA += 1, Arbeiten und -= 1
Job-B macht das dann genauso.
Du musst dir halt nur noch überlegen, in welchem Job du die DTAARA's wieder auf 0 zurücksetzt.
Die Frage ist ja noch, wie der Job denn gekillt wird.
Bei *IMMED hast du ja keine Chance, aber bei *CNTRLD könnte der aktive Job ja den Endestatus in seiner Schleife per RTVJOBA ENDSTS(&STS) abfragen und dann selber aufräumen.
Oder rennt der Job eh nur einmal durch ?
-
Hallo Picachu,
das hört sich gut an. Unsere Programmierer habe gesagt, das sie sich noch nie mit den Sperrstufen befasst haben. Wenn Sperre dann *excl. Wir werden das probieren, vielen Dank
Herr Fuerchau
ich weis nicht genau, wie sich diese Jobs abmelden. ich weis nur, das es in der vergangenheit IMMER völlig problemlos lief. Diese Sperr Situation ist neu. Wir werden den Vorschlag von Picachu an einem 'Pärchen' ausprobieren
Vielen Dank
Dietlinde Beck
-
 Zitat von dibe
Hallo Picachu,
das hört sich gut an. Unsere Programmierer habe gesagt, das sie sich noch nie mit den Sperrstufen befasst haben. Wenn Sperre dann *excl. Wir werden das probieren, vielen Dank
Hallo Dietlinde,
zumindest hört es sich so an, als wäre Job-B der Kandidate für eine Exklusive Sperre. Die muss dieser immer prüfen, und dann setzen. Job-A muss diese Sperre auch prüfen. Aber letztlich ist es auch eine Frage des Designs. Geht es um eine Tabelle, die tot umfällt, wenn mehrere Jobs darauf zugreifen?
-h
-
Hallo Dietlinde,
wie wäre es mit folgender Variante:
Job-A macht immer beim Aufruf:
ALCOBJ OBJ((D1 *DTAARA *SHRRD)) WAIT(0)
Wenn es nicht geht, dann Ende.
Job-B macht immer beim Aufruf:
ALCOBJ OBJ((D1 *DTAARA *EXCL)) WAIT(0)
Wenn es nicht geht, dann Ende.
Job-A kann dann immer laufen, solange kein Job-B läuft,
und Job-B kann dann immer laufen, solange kein Job-A und kein anderer Job-B läuft.
Am Ende der Arbeit sollte jeweils noch ein DLCOBJ stehen, damit bei interaktivem Aufruf die Sperre wieder gelöst wird.
Nach Abbruch des Jobs egal aus welchem Grund ist die Sperre von selbst wieder weg.
Das ist es doch, was Du wolltest, oder?
D1 ist irgendein Objekt, ich nehme am liebsten DTAARAs mit sprechendem Namen.
Gruß, Christian
-
Das ist ja genau das Problem.
Sobald ein mal ein ALCOBJ *EXCL abgesetzt wird, ist kein 2. Aufruf möglich.
Das Szenario ist aber:
Job-A darf beliebig oft parallel laufen aber nicht wenn Job-B läuft.
Job-B darf beliebig oft parallel laufen aber nicht wenn Job-A läuft.
Damit fällt jegliche Exclusiv-Sperre aber weg!
-
naja, ich hatte Dietlinde anders verstanden:
Job-b läuft auch interaktiv und im batch, darf nie mit job-a aber auch nie mit anderen Job-b's laufen.
und dann gehts, wie ich beschrieben habe.
Wenn das Szenario so ist, wie Du schreibst, geht es auch, ist allerdings etwas komplizierter:
Code:
Job-A:
versucht ALCOBJ OBJ((D2 *DTAARA *EXCL)) WAIT(0)
versucht ALCOBJ OBJ((D1 *DTAARA *SHRRD)) WAIT(0)
Wenn beides geht, macht er
DLCOBJ OBJ((D2 *DTAARA *EXCL))
startet die Verarbeitung
und anschl. DLCOBJ OBJ((D1 *DTAARA *SHRRD))
Job-B:
versucht ALCOBJ OBJ((D1 *DTAARA *EXCL)) WAIT(0)
versucht ALCOBJ OBJ((D2 *DTAARA *SHRRD)) WAIT(0)
Wenn beides geht, macht er
DLCOBJ OBJ((D1 *DTAARA *EXCL))
startet die Verarbeitung
und anschl. DLCOBJ OBJ((D2 *DTAARA *SHRRD))
-
Huch, was hab ich nur ausgelöst ...
cbe
Genau so wie von Ihnen beschrieben haben wir es von Picachu verstanden und umgesetzt.
Test laufen noch, sieht bisher gut aus.
Fuerchau
cbe hat recht, Job-b darf nur einmal laufen, sorry wenn das nicht klar rüber kam.
holgerscherer
die genauen Hintergründe kenne ich nicht. Jedenfals nicht so, das ich sie anderen erklähren könnte. Eins weis ich aber. Man könnte den gesammten Ablauf umprogrammieren um dieses Problem zu beseitigen. Der Aufwand wird auf über 4 Monate + Test benannt. Da ist ein halber Tag hier im Forum günstiger.
vielen Dank an alle
DiBe
-
 Zitat von dibe
cbe
Genau so wie von Ihnen beschrieben haben wir es von Picachu verstanden und umgesetzt.
ups, wer lesen kann ist im Vorteil
Pikachu, ich hoffe Du verzeihst mir, dass ich Deinen Beitrag wohl irgendwie nicht richtig gelesen hatte...
-
Ja OK, das mit Job-B hatte ich nicht genau gelesen.
Damit ist Pikachus Lösung ja auch korrekt.
Similar Threads
-
By harkne in forum NEWSboard Programmierung
Antworten: 8
Letzter Beitrag: 12-06-08, 11:03
-
By TARASIK in forum IBM i Hauptforum
Antworten: 1
Letzter Beitrag: 26-10-06, 11:07
-
By wolfmakiol in forum IBM i Hauptforum
Antworten: 13
Letzter Beitrag: 21-08-06, 09:10
-
By bode in forum IBM i Hauptforum
Antworten: 5
Letzter Beitrag: 22-07-06, 11:52
-
By hs in forum IBM i Hauptforum
Antworten: 5
Letzter Beitrag: 12-12-01, 09:43
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks