-
Wenn die ACTGRP benannt ist hat man eine eigene Commit-Umgebung und beim Verlassen des Programmes / der ACTGRP wird bereits aufgeräumt.
Übrigens verwende ich Ardgate mit ACTGRP(*NEW) damit die ACTGRP nicht irgendwie offen bleibt (*INLR = *OFF).
Auch ein häufiges Erstellen neuer ACTGRP's dauert ja nicht mehr lange.
-
Zitat von Fuerchau
Wenn die ACTGRP benannt ist hat man eine eigene Commit-Umgebung und beim Verlassen des Programmes / der ACTGRP wird bereits aufgeräumt.
Übrigens verwende ich Ardgate mit ACTGRP(*NEW) damit die ACTGRP nicht irgendwie offen bleibt (*INLR = *OFF).
Auch ein häufiges Erstellen neuer ACTGRP's dauert ja nicht mehr lange.
Mal eine Laienfrage, weil wir selten die ACT Groups manipulieren.
Was muss ich machen, damit das RPG (mySQL Access) unter einer eigenen ACTGRP läuft?
SBMJOB call CL, call RPG (mySQL).
Dankeschön.
Gruß Klaus
-
Zitat von itec01
Mal eine Laienfrage, weil wir selten die ACT Groups manipulieren.
Was muss ich machen, damit das RPG (mySQL Access) unter einer eigenen ACTGRP läuft?
SBMJOB call CL, call RPG (mySQL).
Dankeschön.
Gruß Klaus
... die ACTGRP hängt am Programm, bzw. SrVPGM und wird beim CRTPGM, bzw. CRTSRVPGM festgelegt. Beim SBMJOB muss/kann man da nix machen.
D*B
-
Im Header der Quelle definieren:
ACTGRP('NAME') DFTACTGRP(*NO)
Serviceprogramme sollten nach Möglichkeit (bis auf gezielte Ausnahmen) nur *CALLER haben, was der Default ist.
-
Danke, aber die Änderungen der Activation Group hat das Problem nicht gelöst. Wir schauen nun, welche Commits offen sind.
-
... zumindest für den local change (letzte Meldung), müsste das im Journal zu finden sein.
D*B
-
Hallo,
es ist so, dass JVAGATE offene API commits stehen lässt und zwar aus dem Program CCEXIT kommend. Beim Beenden des Jobs werden die dann zurückgefahren.
Schon bei dem Connect zur fremden DB tauchen die Commits auf und verschwinden bis zum Ende des Programmes nicht.
Anbei die hardcopies:
-
... JVAGATE registriert eine externe Commit Ressource per API QTNADDCR, um commit Operationen auf die externen Connects auszuführen, wenn lokal eine commit Operation angefordert wird. Der Commit Handler CCEXIT wird dann von der Datenbank nach jeder Commit Operation automatisch aufgerufen und propagiert die commit Operation auf die remote Datenbanken. Wenn dabei lokale Commit Definitionen offen bleiben, ist das eine Defektproblem von OS/400 bzw. neudeutsch I.
D*B
-
Zitat von BenderD
... wenn lokal eine commit Operation angefordert wird. Der Commit Handler CCEXIT wird dann von der Datenbank nach jeder Commit Operation automatisch aufgerufen und propagiert die commit Operation auf die remote Datenbanken. Wenn dabei lokale Commit Definitionen offen bleiben, ist das eine Defektproblem von OS/400 bzw. neudeutsch I.
D*B
Wie ist das mit den lokalen db's zu verstehen? In meinem Beispiel gibt es keine lokalen DB's und wie in meiner Beschreibung zu erkennen, ist auch nur das JVAGATE API offen, sonst nichts. Daher verhält sich JVAGATE meiner Meinung nicht sauber und lässt Commits offen.
-
... so wie beschrieben! Du startest ein Programm unter commit, das erstellt eine lokale commit Definition, ArdGate hängt einen exit handler dran und propagiert genau die commit Operationen, die Dein Programm ausführt. Nicht mehr und nicht weniger. Das Problem liegt entweder in Deinem Programm oder der Datenbank fehlt ein PTF. ArdGate startet weder transactions, noch schreibt ArdGate irgendwas, was Dein Programm nicht anfordert.
D*B
-
Ok, Dieter, wir lassen das erst mal so. Die SQL's funktionieren ja.
Danke Dir.
-
Noch eine Frage an die Profis bezüglich JVAGATE und Commit für beide Welten.
Anforderung:
Tabellen stehen in MySQL und auf der AS/400.
1. Step: mysql tabellen lesen und Sätze sperren
2. gelesene Informationen verarbeiten und mit zusätzlichen Information aus AS/400 Tabellen in eine AS/400 Tabelle schreiben (RPG WRITE). Diese liegt auch unter Commit
3. Wenn die AS/400 Tabelle sauber erzeugt wird, erfolgt der SQL update auf die MySQL Tabellen
4. Wenn OK, SQL commit auf MySQL und RPG Commit auf AS/400 Tabelle
Dies haben wir in einem RPG Programm versucht, leider bricht das Programm beim OPEN der AS/400 Tabelle ab. Ich habe hier etwas gelesen, dass es wohl besser wäre 2 Programme in unterschiedlichen Aktivierungs Gruppen zu machen, bin mir aber nicht sicher.
Wir macht Ihr das?
Danke.
Gruß Klaus
Similar Threads
-
By Peet in forum NEWSboard Programmierung
Antworten: 10
Letzter Beitrag: 16-04-20, 13:02
-
By Peet in forum NEWSboard Programmierung
Antworten: 5
Letzter Beitrag: 25-06-19, 10:59
-
By labm in forum NEWSboard Programmierung
Antworten: 20
Letzter Beitrag: 05-06-18, 08:09
-
By svit in forum NEWSboard Programmierung
Antworten: 14
Letzter Beitrag: 18-09-14, 11:14
-
By itec01 in forum IBM i Hauptforum
Antworten: 3
Letzter Beitrag: 08-07-14, 10:17
Tags for this Thread
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