Java und die Verbindung von außen über eine Dataq

[BenderD]

... wenn das alles stimmt, was Du da schreibst, dann ist die DataQ Koponente der Dollschachtel Buggy. Ich vermute allerdings eher, dass da jemand in diesem Gestrüpp von rename auf der einen Büchse und restart auf der anderen Büchse über die eigenen Füße fällt.

D*B, dem schon wieder übel wird

[Robi]

Tja, so ist nunmal das Konstrukt.

Eine externe Firma liest Daten aus eine Dataq (vom PC, aus der Testumgebung)
Die Testumgebung wird jeden Samstag(da arbeitet keiner) aus der Echtungebung neu erstellt.
Die alte Testumgebung wird für 1 Woche gerettet als Test_old (rename)
Und Montag morgen konnten die PC-Firma keine Daten aus der Dataq lesen, bis wir Daten in die test_old/dataq geschrieben haben. Angeblich haben die Ihre PC-Pgmme morgens beendet und neu gestartet.
Und nun brauch ich ne Idee, da andere Java Pmme, die via Dataq mit uns (RPG) kommuinizieren dieses Problem nicht haben. Und das alles ohne Java Kentnisse

[Fuerchau]

Raten im Nebel ist da unproduktiv.
Ohne den Quellcode kann dir da wohl keiner was sagen.

[BenderD]

Angeblich

... da hammers doch ...

[Robi]

@Dieter,
ja, aber das ist schon relativ sicher, alles andere wäre Betrug!

@Baldur
Code einsicht bekommen wir Montag, wenn unser Java-Pgmmr wieder da ist.
aber bis Montag ist noch lang ... und der Fehler ein 2. mal da!

[Fuerchau]

Mittels ENDPJ kannst du die Java-Servicejobs beim Umhängen der Lib ja killen (allerdings sind dann alle betroffen) und per STRPJ wieder starten.

[Pikachu]

Die Vermutung ist wohl richtig (siehe die Anmerkungen zu "Library name" der Send Data Queue" (QSNDDTAQ) API und Receive Data Queue (QRCVDTAQ) API). Es sind also wahrscheinlich die APIs auf der AS/400, die sich die Speicheradresse der umbenannten Datenwarteschlange gemerkt haben und über diese Speicheradresse weiterhin auf diese zugreifen.

[Robi]

Ja, danke.
Deshalb suche ich ja nach einem
'Beende die Verbindung zur AS/400 und alle von mir benutzen Zugriffswege' - Befehl im Java

Robi

[Pikachu]

Das hat nichts mit der Verbindung zur AS/400 oder Java zu tun.
Das ist eine Eigenschaft der Datenwarteschlangen-APIs der AS/400.
Da hilft vielleicht nur ein IPL.

[Robi]

Jain,

Es ist ja der JavaJob, der die zusätzlichen Jobs in dem Q*WRK Subsystem verursacht.
Also soll das beenden des Javajobs auch diese dinger zumachen.

Aber ich vermute, das das nicht geht und wir alle Jobs des Users abschießen müssen.
Blöd ist nur, das ggf. gerade in dem Moment andere User diese 'Datenzugriff'-Jobs verwenden, der Job aber weiterhin das USEPRF aus dem Javajob sperrt.
(War der Tipp von Baldur, mit "WRKOBJLCK usrprf *USRPRF" die Jobs zu finden

Im Joblog eines solchen Jobs haben wir jedenfalls schon Meldungen gefunden, die mit dem Java-dataq-lesen überhaubt nix zu tun haben, sondern aus unserer GUI kommen.

Robert

[Fuerchau]

Das soll verstehen wer will.
Wenn ich gezielt eine DTAQ YYY in der Lib XXX auswähle, sollte nichts anderes genommen werden.
das Standard-API QRCVDTAQ/QSNDDTAQ cached da überhaupt nichts.
Auch wenn ich Remote per API da direkt was angebe wird nichts gecached.

Es kommt nun auf die verwendeten Methoden in dem Java-Programm an, ob dieses selber irgendwo die Objektbeziehung zur DTAQ cached bzw. in einer Variablen hält und daher die Änderung nicht mitbekommt.
Hier wird ggf. zur Laufzeit das DTAQ-Objekt bei Verbindungstrennung nicht zerstört um es neu aufzubauen.
Da hilft auch kein IPL.

Ohne Quelle geht da nichts.

[Pikachu]

Auszug aus der Beschreibung des Receive Data Queue (QRCVDTAQ) APIs:

Note: To improve data queue performance, the data queue APIs remember addressing information for the last data queues used. This occurs when a specific (not *LIBL or *CURLIB) value is provided for the library name, and the data queue is located in the system auxiliary storage pool (ASP number 1) or a basic user ASP (ASP numbers 2-32). The addressing information for data queues located in independent ASPs is not saved.

Because the addressing information is saved, users of this API should be aware of the following scenarios.

Scenario 1

If, a job references a library-specific data queue, the data queue is moved using the Move Object (MOVOBJ) command or renamed using the Rename Object (RNMOBJ) command, and a new data queue is created with the same name and library as the data queue that was renamed or moved, then, the job continues to reference the original data queue, not the newly created data queue.

...