OVRDBF auf eine bereits überschriebene Datei

[Starocotes]

Danke erstmal.

Ich hab jetzt beides probiert aber in jedem Fall ersetzt er die Überschreibung.
Bei dem Secure(*YES) bezieht er sich glaub ich nur auf die Paramter. Wenn ich aber auf eine neue Datei überrschreibe ersetzt der das komplett.

Also doch in die Tiefen einsteigen.

[Robi]

Eine bereits offene Datei kann nicht neu überschrieben werden.
Ist das ggf. ein ACTGRP Thema?
OVR auf *JOB ebene,
SHARE(*yes)
und die Datei öffnen ! (zur Not mit einem RPG-PGM 3-Zeiler)
Robi

[Fuerchau]

Share bezieht sich wie gesagt nur auf bereits offene Dateien.
Mache ich einen OVRDBF will ich ja eine andere Datei und nicht auf eine bereits geöffnete Datei zugreifen.
Share(*YES) ist sowieso gefährlich, da ich mich damit nicht mehr auf Dateizeiger verlassen kann.
Ich mache schon mal Änderungen in "alten" ERP's und mache da schon mal OVRDBF SHARE(*NO) um einen eigenen Zeiger zu erhalten.

[Starocotes]

Eine bereits offene Datei kann nicht neu überschrieben werden.
Ist das ggf. ein ACTGRP Thema?
OVR auf *JOB ebene,
SHARE(*yes)
und die Datei öffnen ! (zur Not mit einem RPG-PGM 3-Zeiler)
Robi

Ah, jetzt Ja.

Das werde ich mal testen, Danke.

[Starocotes]

Okay, kann ich auch vergessen:

Bei mir sieht das in etwa vereinfacht folgendermaßen aus:

ProgrammA

If Schalter
OVRDBF FILE(DateiX) TOFILE(DateiY)
Endif

open DateiX
Machwas
close DateiX

call ProgrammB

ProgrammB

If Schalter
OVRDBF FILE(DateiX) TOFILE(DateiY)
Endif

open DateiX
Machwas
close DateiX

Selbst bei nem SHARE(*YES) und nem open vorher würde ja ProgrammB wieder den OVRDBF machen können.

Ich denke ich lege mir noch nen Datenbereich an den ich einlese und als neuen Schalter verwende nur für MEIN OVRDBF verwende.

[Starocotes]

Sorry, muss euch nochmal als "Reflektor" missbrauchen.

Datenbereich ist nicht weil die Programme in Theorie paralell laufen können.
Datenbereich in QTEMP würde wieder voraussetzen, das ich zuerst prüfe ob der da ist weil ProgammA und ProgrammB auch woanders aufgerufen werden können.

Wo bekomme ich nen Jobbedingten Parameter her der "automatisch" da ist?

[Robi]

???????????
Der LDA ist Jobbedingt
Parallel interaktiv im selben job geht nicht
Parallel im Batch = 2 LDA

oder was meinst du?
Robi

[Starocotes]

ProgrammA kann in unterschiedlichen Jobs parallel laufen. Da hab ich ja dann unterschiedliche LDA's.
Denn kann ich aber nicht verwenden da der in zu vielen anderen Programmen gleich genutzt wird.

Ne statische Datenstruktur geht nicht weil dann ja beim Parallelbetrieb eventuell was durcheinander kommen würde.

Bin gerade am prüfen ob ich nicht doch einen Übergabeparameter missbrauchen kann.

[Fuerchau]

Missbrauch ist immer schlecht.
Aber die LDA kann man schon benutzen (ich mache das auch häufig):
- Ursprüngliche LDA (1KB) komplett einlesen
- LDA modifizieren, CALL oder SBMJOB
- LDA wiederherstellen

Beim SBMJOB wird die lokale LDA kopiert und an den Batchjob übergeben.

[BenderD]

... da könnte man doch einen UserSpace mit Pxxxxxx (xxxxxx = Jobnummer und P ein Prefix erstellen), das ist dann gleich auf 26 Stück erweiterbar, den könnte man dann noch über LIBL suchen lassen, beim SBMJOB kann man dann den LDA da rein sichern und den Namen des zu verwendenden USRSPC in den LDA reinmalen und dann im aufgerufenen Jobe wieder alles richtig rumkopieren; das müsste doch genug hergeben, dass man die Programme garnicht mehr versteht...

D*B

[Starocotes]

Danke für die Hilfreichen Antworten, habe mich gerade entschieden das komplette Programm in Assembler auf nem 286 neu zu schreiben oder alternativ hab ich hier auch noch 2 Programmtafeln zum Stecken rumliegen

LDA sichern ist nicht, weil es doch ein wenig komplexer ist und ich die Daten aus dem LDA auch brauche.
Werd das jetzt mit dem Parameter probieren.

[Pikachu]

Vorsicht mir der Jobnummer! Es kann durchaus (wenn auch sehr selten) mehrere (aktive) Jobs mit derselben Jobnummer geben, solange sich diese Jobs im Benutzernamen oder Jobnamen unterscheiden.