Globale SQL-Variable im RGP-Programm füllen

[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