Globale SQL-Variable im RGP-Programm füllen

[Sebastian85]

Hallo,
ich stehe mal wieder auf den SQL Schlauch.

Es wurde eine gloable SQL-Variable erstellt.
CREATE OR REPLACE VARIABLE
Lib1.gv_cTest CHARACTER(1) DEFAULT NULL;

Diese Variable wird mittels embeddet SQL in einem RPG-Programm (PgmA) wie folgt gefüllt:
exec sql
set Lib1.gv_cTest = 'A';

Aus dem Programm PgmA wird das RPG-Programm PgmB aufgerufen.
In einem embedded SQL-Statement in Programm PgmB wird die globale Variable gv_cTest in der Where-Klausel verwendet. Jedoch ist die globale Variable gv_cTest nicht gefüllt.

Kann mir jemand weiterhelfen, warum die globale SQL-Variable gv_cTest in PgmB nicht mehr gefüllt ist, obwohl sie im PgmA gefüllt wurde?

[Fuerchau]

Das weiß ich auch nicht. Aber ehrlich gesagt: das mit den globalen Variablen würde ich absolut lassen, denn das verwirrt mehr als es zu Lösungen beiträgt, wie du gerade selber feststellst.

Sind ggf. unterschiedliche ACTGRP's im Spiel?
Schließlich hat jede ACTGRP seine eigene Verbindung zur Datenbank.

[Sebastian85]

Die meisten Programme starten mit ACTGRP(*NEW).
Daher könnte das Problem kommen.

Ich dachte immer, die Variable wird für den Job gefüllt.
Da ist es wirklich zu überlegen, ob man die Finger von den globalen Variablen lässt.

Vielen Dank schonmal für die Info.

[Fuerchau]

Birgitta weiß da bestimmt mehr drüber.
Ich finde den Ansatz für nicht zielführend, da man im Endeffekt ja nie sicher sein kann, ob die Variable auch wirklich den korrekten Wert beinhaltet.
Z.B. schiebt man schon mal gerne Wrapper-Programme zwischen die Aufrufe (durch LIBL-Veränderungen).

[Sebastian85]

Wir haben eine eigene Benutzerverwaltung.
Beim Anmelden des Users, werden bestimmte Parameter gesetzt, die während des Jobs nicht geändert werden.
Ziel ist es, dass wir die Parameter in globale Variable schreiben um sie nicht immer aus unserer Parameterverwaltung zu lesen. Somit wollen wir unsere SQL-Programmen bzw. Views performanter gestalten.

Birgitta, hast du noch einen Rat?

[KM]

Globale SQL-Variablen haben Session Scope. Deshalb wird wohl beim Aufruf eines weiteren Programms eine neue SQL-Session gestartet (siehe Link!):

http://www.rpgpgm.com/2016/05/global...e-data-in.html

Vielleicht wäre es für Dich auch eine Option stattdessen mit Umgebungsvariablen zu arbeiten? Die kannst Du auf Job-Ebene definieren.

Gruß,
KM

[Fuerchau]

Und wenn dann jedes Programm mit ACTGRP(*NEW) erstellt wurde, erhält dieses auch jeweils seine eigene SQL-Session, die tatsächlich auch nur von diesem Programm erreichbar ist.
Aber globale Variablen lassen sich ebenso mit einer normalen Tabelle, in der z.B. der User als Schlüssel hinterlegt ist, ersetzen ohne dass man dadurch Performance verliert:

select .....
from FromFile ff ...
join ...
, lateral (select * from ParamFile where Key = user) pp
where ff.Key = pp.ParamX ...

Bevor es Parameter gab, hat man dies doch schon immer so gelöst (statt komfortablem "lateral ..." ging eben auch ein
inner Join ParamFile on Key = User