keine Rekursion möglich !? Ich versteh's nicht...

[flieger_siggi]

Hallo,

ich habe in einem SRVPGM eine Funktion, die sich selbst rekursiv aufruft. Teste ich diesen Funktionsaufruf direkt interaktiv mit einem Programm, ist alles bestens. Im Batch aber bekomme ich immer einen MCH4429, Überlauf bei dynamischem Speicher???
Die Meldung kommt, sobald die Rekursion das erste mal aufgerufen wird.
Ich versteh' das nicht...

Bin für jede Anregung dankbar.

Siggi

[dschroeder]

Hallo Siggi,

möglicherweise hast du deine Variablen so groß definiert, dass der Speicher fast vollständig alloziiert wird. Wenn in deinem interaktiven Testprogramm nichts weiter gemacht wird, reicht der Speicher vielleicht so eben. Wenn das Batchprogramm dagegen aber noch mehr macht und selber auch noch einiges an Speicher alloziiert, reicht es eben nicht mehr.

Du kannst ja mal mit DSPSRVPGM feststellen, wieviel Speicher fest alloziiert wird. Bei 16 MB ist Schluss (meine ich).

Dieter

[flieger_siggi]

Hallo Dieter,

die Größe des festen Speichers ist mit 29360 angegeben...

[dschroeder]

OK,
das ist ja noch nicht so viel. Aber ich denke, dass bei jedem Rekursionsaufruf neuer Speicher alloziiert wird und das alles in die 16 MB Begrenzung reinfließt. Hast du mal getestet, ob dein Programm direkt bei der ersten Rekursion abschmiert oder ob der Speicher erst bei der x-ten Rekursion zu Ende ist?

[dschroeder]

Sorry, habe gerade gelesen, dass du ja schon geschrieben hast, dass das bei der ersten Rekursion passiert. Du kannst ja nochmal mit wrkjob gucken, wieviel Speicher der Job maximal benutzt.

[andreaspr@aon.at]

Was steht noch mehr im Joblog?
(Ursache, vorherige Fehlermeldungen --> Folgefehler?!)

lg Andreas

[flieger_siggi]

Hallo Andreas,

es gibt keine vorherigen Fehlermeldungen. Sobald die Funktion das erste mal rekursiv aufgerufen wird, kommt der Fehler hoch.

Kleine Ergänzung: das Programm, das die Funktion das erste mal aufruft (also von aussen) wird per "spawn" gestartet. Kann es daran liegen?

Siggi

[andreaspr@aon.at]

Zumindest gibt es unter der MSG-ID MCH4429 noch mehr zu lesen als nur den einen Satz.

Nachricht . . . :   Überlauf bei dynamischem Speicher.                        
Ursache  . . . . :  Einer der Stacks &1 im dynamischen Speicher für den Thread
  ist übergelaufen, oder es wurde ein Speicherzugriff außerhalb der maximalen 
  Größe eines Stacks eines dynamischen Teraspace versucht. Die weitere        
  Ausführung des Programms innerhalb des Threads ist nicht möglich.           
  Stack-Werte für den dynamischen Speicher und ihre Bedeutung:                
    1 -- System-Stack im Ein-Speicher-Adressraum.                             
    2 -- Benutzer-Stack im Ein-Speicher-Adressraum.                           
    3 -- System-Stack im Teraspace.                                           
    4 -- Benutzer-Stack im Teraspace.

Wäre vielleicht auch nicht uninteressant zu wissen um welchen Stack es sich da handelt.

Des weiteren starte ein DB-Monitoring. Wenn das Problem im SQL Liegt sollte es auch noch ein paar SQL Fehlermeldungen geben. Die vielleicht überlesen werden. (Vielleicht Folgefehler)

"spawn" kenne ich nicht.

[flieger_siggi]

Hallo Andreas,

SQL ist nicht involviert, ich lese eine Datei per READE in der Prozedur.

Es ist der Stack 2, der überläuft.

Mit spawn werden neue Threads erstellt.

lg
Siggi

[BenderD]

... ist sichergestellt, dass der spawn nicht das problem ist?
ALWMLTTHD beim SBMJOB, activity level des Subsystems auch die RPG runtime hat ihre Krämpfe mit Multi-threading...

D*B

[flieger_siggi]

Moin,
gestern war Urlaub...
In der gleichen Umgebung laufen auch andere multi-threaded Anwendungen.
Hat niemand weitere Ideen?

Siggi

[B.Hauser]

Hast Du zufällig in den H-Bestimmungen THREAD(*SERIALZED) hinterlegt?

Wenn nicht binde das Schlüssel-Wort ein, das sollte dafür sorgen, dass ein Job in einer multi-threading Umgebung "thread-safe" läuft.

Unter welchem Release arbeitet ihr überhaupt?

Birgitta